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entire  system.  9.  Providing  computer  assistance  for  task 

The  proposed  ECS  system  represents  a  management  layer  between  the  user  interface  (supporting  two  user  classes, 
managers  and  designers)  and  the  design  database  which  contains  a  record  of  the  versions  of  all  software  objects  and 
planned,  active  and  completed  evolution  steps. 
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ABSTRACT 


This  dissertation  introduces  an  Evolution  Control  System  (ECS)  for  the  Computer 
Aided  Prototyping  System  CAPS.  The  purpose  of  the  ECS  is  to  automate  the  scheduling 
and  the  assignment  of  tasks  to  the  software  designers  based  on  management  policies  and 
the  dependencies  in  a  model  of  the  software  configuration.  The  ECS  controls  the  software 
evolution  process  in  an  incrementally  evolving  software  system  where  the  steps  to  be 
scheduled  are  only  partially  known.  Time  required,  the  set  of  sub-tasks  for  each  step,  and 
the  input/output  constraints  between  steps  are  all  uncertain,  and  arc  all  subject  to  change  as 
evolution  steps  are  carried  out.  The  ECS  provides  computer  assistance  for  managing  such 
changes  and  panially  automates  the  control  of  the  design  team  and  the  project  data. 

The  ECS  manages  both  the  development/prototyping  data  and  the  design  team  through 
scheduling  the  software  tasks  and  assigning  them  to  members  of  the  design  team.  The  main 
goals  of  this  system  are:  I.  Managing  the  evolution  step.s  from  the  moment  they  are 
proposed  until  their  completion.  2.  Reaching  a  feasible  schedule  that  meets  the  deadline 
requirements  or  minimizes  the  largest  amount  that  a  deadline  is  missed  if  all  deadlines 
cannot  be  met  and  provides  for  the  earliest  possible  completion  for  those  steps  that  either 
do  not  have  deadlines  or  have  under-estimated  deadlines.  3.  Maximizing  the  efforts  of 
software  designers  by  maximizing  concunent  assignments.  4.  Supporting  incremental 
replanning  as  additional  information  becomes  available.  S.  Minimizing  wasted  design 
effort  due  to  schedule  reorganization  as  well  as  workers  forced  to  wait  for  completion  of 
sub-tasks.  6.  Insuring  system  integrity  via  propagation  of  change  consequences  (induced 
steps)  to  maintain  the  global  consistency  of  the  database  and  providing  serializability  of 
updates.  7.  Cfriciciu  use  of  space  and  time  for  the  design  database  and  scheduling 
algorithm.  8.  Automating  the  process  of  determining  which  versions  of  the  subcomponents 
belong  to  each  version  of  the  entire  system.  9.  Providing  computer  assistance  for  task 
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decomposition  during  planning  using  decomposition  and  dependency  information  of  the 
previous  version  of  the  software  system. 

The  proposed  ECS  system  represents  a  management  layer  between  the  user  interface 
(supporting  two  user  classes,  managers  and  designers)  and  the  design  database  which 
contains  a  record  of  the  versions  of  all  software  objects  and  planned,  active  and  completed 
evolution  steps. 
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I.  INTRODUCTION 


A.  PURPOSE 

The  main  objective  of  this  dissertation  is  to  design  an  evolution  control  system  that  can 
provide  automated  assistance  for  the  software  evolution  process  in  an  uncertain 
environment  where  designer  tasks  and  their  properties  are  always  changing.  The  software 
evolution  process  involves:  1)  The  software  users  (customers)  who  initiate  the  change 
requests  whether  they  are  corrective,  adaptive,  or  perfective  changes  (31,  2)  The  software 
manager  or  change  control  board  who  reviews  these  change  requests  and  approves/rejects 
the  changes  for  implementation,  3)  The  evolution  team  that  has  the  task  of  implementing/ 
verifying  these  changes.  4)  and  finally  the  software  system  under  evolution  that  must 
preserve  its  consistency  and  keep  enough  information  about  its  evolution  history. 

We  view  an  Evolution  Control  System  (ECS)  as  the  agent  that  keeps  track  of  proposed, 
ongoing,  and  completed  changes  to  a  software  system.  It  provides  automated  assistance  to 
the  software  evolution  manager  to  help  him/her  to  make  the  right  decisions.  It  automatically 
propagates  change  consequences  by  defining  the  set  of  possibly  affected  modules.  It  also 
coordinates  and  plans  change  implementation  activities  within  the  design  team  in  a  way 
that  supports  team  work  and  guarantees  system  integrity,  as  well  as  adapting  itself  to  the 
dynamic  nature  of  the  evolution  process  where  new  changes  arrive  randomly  and  current 
modifications  are  themselves  subject  to  change  as  more  information  becomes  available. 

The  above  definition  implies  that  an  ECS  has  two  main  functions.  The  first  is  to 
control  and  manage  evolving  software  system  components  (version  control  and 
configuration  management,  VCCM)  and  the  second  is  to  control  and  coordinate  evolution 
team  interactions  (planning  and  scheduling  software  evolution  tasks  which  we  refer  to  as 
evolution  steps). 

The  ECS  system  should  manage  both  human  resources  and  the  design  database  and 
provide  the  help  needed  by  the  software  manager  as  well  as  facilitating  the  designers’  usks. 
This  system  provides  the  required  algorithms  for  coordinating  and  executing  the  activities 
mentioned  above  as  well  as  the  algorithms  for  reaching  and  maintaining  a  feasible 
schedule,  if  one  exists,  that  meets  the  deadline  requirements,  reduces/avoids  rollbacks,  and 
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insures  system  integrity  in  an  uncertain  environment  where  the  set  of  evolution  steps  and 
their  properties  are  always  changing. 

B.  SOFTWARE  EVOLUTION 

Software  evolution  is  the  process  of  extending  or  modifying  the  functionality  of  a 
software  system  [II].  Evolution  activities  may  be  triggered  by  changes  in  user 
requirements,  planned  phased  development  of  a  system,  or  by  design  changes  to  eliminate 
errors  discovered  after  system  delivery  (repair).  Evolution  (maintenance)  activities  account 
for  65%  to  75%  of  total  cost  of  a  software  system  [71],  Software  evolution  involves  change 
requests,  software  systems,  evolution  steps,  customers,  managers,  and  software  engineers. 
Customers  provide  change  requests,  and  the  corresponding  changes  are  controlled  by  the 
managers  of  the  software  system.  Approved  changes  trigger  evolution  steps  that  produce 
new  versions  of  the  software  system.  Evolution  steps  are  scheduled  based  on  management 
policies,  and  are  executed  by  the  software  engineers  [52]. 

C.  SOFTWARE  EVOLUTION  MODELS 

While  detailed  software  process  models  are  still  a  subject  of  research,  there  are  some 
general  models  (paradigms)  of  software  development  that  can  be  identified.  Some  of  these 
software  development  models  are[71]: 

1.  The  waterfall  model:  This  model  views  the  software  process  as  a  cascade  of  a  number 
of  phases  such  as  requirements,  specification,  design,  implementation,  testing  and 
maintenance  phase. 

2.  Exploratory  programming:  In  this  approach  a  working  system  is  rapidly  developed, 
then  repeatedly  modified  until  it  reaches  an  adequate  functionality.  This  model  is  used 
where  detailed  requirements  cannot  be  specified  and  where  adequacy  rather  than  the 
correctness  is  the  main  goal  of  system  designers. 

3.  Prototyping;  This  approach  is  similar  to  the  exploratory  programming,  but  the  main 
goal  is  establishing  the  system  requirements.  TTiis  norm^ly  followed  by  an  implemen¬ 
tation  of  the  requirements  to  obtain  a  production  quality  system. 

4.  Formal  transformation:  In  this  approach  a  formal  specification  of  the  system  is  devel¬ 
oped  then  transformed  to  a  program  using  correctness  preserving  transformations. 

5.  System  assembly  from  reusable  components:  This  approach  uses  the  assumption  that 
systems  are  mostly  made  up  of  already  existing  components.  This  means  that  the  sys¬ 
tem  development  bo;omes  an  assembly  rather  than  a  creation  process. 
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These  models  are  normally  called  software  life  cycle  models  to  cover  the  period  from 
conception  to  retirement  of  a  given  software  system.  This  means  that  the  evolution 
activities  can  follow  the  same  model  followed  in  the  development.  In  some  of  these  models 
evolution  starts  after  the  release  of  the  developed  system,  like  the  waterfall  model  in  which 
the  evolution  activities  go  through  the  same  cascaded  phases  of  the  model.  In  some  other 
models  like  exploratory  programming  and  evolutionary  prototyping  the  current  system  can 
be  viewed  as  a  snapshot  of  an  evolving  system  that  evolves  from  an  empty  system  through 
continuous  iterations  of  evolution  steps. 

D.  PROTOTYPING  PROCESS 

Prototyping  is  a  technique  to  help  establish  and  validate  system  requirements. 
Prototyping  in  the  software  process  is  practiced  in  two  diherent  forms;  the  first  is  “throw¬ 
away”  prototyping  where  a  prototype  is  developed  with  the  objective  of  specifying  system 
requirements.  After  the  customer  is  satisfied  with  the  requirements  the  prototype  is 
discarded  and  the  system  is  built  from  scratch. 

The  second  form  is  evolutionary  prototyping  where  a  prototype  evolves  via  a  number 
of  versions  to  the  final  system.  Evolutionary  prototyping  lends  itself  as  an  evolution  model 
where  the  system  is  started  from  its  fundamental  concepts  and  is  then  iteratively  modified 
in  an  interactive  way  with  the  customer  until  the  system  reflects  the  customer’s  real  needs 
151]. 

Prototyping  techniques  include  the  use  of  executable  specification  languages  and 
reusable  software  components  for  rapid  prototype  construction. 

E.  PROBLEM  DEHNITION 

With  the  complexity  of  software  systems  growing  every  day,  more  sophisticated 
development  and  maintenance  environments  are  necessary  to  cope  with  the  evolutionary 
nature  of  software  systems.  These  systems  experience  iterative  modifications  through  many 
versions  to  cope  with  the  customer’s  changing  and  growing  needs  and  the  changing  and 
growing  software  and  hardware  technology. 

In  the  context  of  an  evolving  system,  a  software  evolution  step  is  used  to  represent  the 
activities  of  analyzing  and  implementing  one  change  request  These  evolution  steps  arc 
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typically  only  partially  known.  Time  required,  the  set  of  sub-tasks  for  each  step,  and  the 
input/output  constraints  among  steps  are  all  uncertain,  and  are  all  subject  to  change  as 
evolution  steps  are  carried  out. 

Scheduling  these  evolution  steps  without  taking  into  account  their  special  nature,  as 
mentioned  above,  complicates  the  management  task  of  achieving  the  best  possible 
utilization  of  human  and  machine  resources.  This  also  may  lead  to  software  rollbacks  which 
waste  programming  efforts,  and  affect  software  consistency  due  to  the  lost  coordination 
between  engineers  working  on  different  evolution  steps  that  may  be  related  to  each  other. 

An  evolution  control  system  must  account  for  all  the  interacting  factors  of  the 
evolution  process.  These  factors,  as  discussed  above,  include  change  requests  that  are 
provided  by  the  customers  and  lead  to  the  creation  of  corresponding  evolution  steps.  These 
steps  are  controlled  by  the  manager  of  the  software  system.  Approved  steps  are  scheduled 
for  implementation  by  software  designers.  The  completed  steps  produce  new  versions  of 
the  software  system.  Controlling  an  evolving  system  means  coordinating  these  interactions 
in  a  way  that  preserves  system  integrity,  supports  team  work  via  maximizing  the  number 
of  concurrent  assignments,  avoids/reduces  rollbacks,  planning  the  required  changes  (steps) 
to  meet  the  management  constraints  such  as  deadlines,  p.ecedences,  and  priorities,  and 
maintaining  a  record  of  these  change  activities  for  history  purposes.  Such  an  evolution 
control  system  should  be  flexible  enough  to  adapt  its  scheduling  and  planning  function,  in 
real-time,  to  the  dynamic  changes  in  current  evolution  steps  as  well  as  the  random  arrival 
of  new  steps. 

F.  CONTRIBUTION  OF  THIS  RESEARCH 
The  main  contributions  of  this  dissertation  are; 

1.  Automated  support  for  changes  in  plan  during  the  execution  of  the  plan. 

2.  Automatic  decision  support  for  planning  and  team  coordination  based  on  design  depen¬ 
dencies  captured  in  the  configuration  model. 

3.  The  enhancement  and  implementation  of  a  conhguration  graph  model  presented  in 
(52],  which  is  used  to  keep  the  evolution  history  of  software  systems. 
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4.  The  development  of  the  specification  and  implementation  of  the  required  mechanisms 
to  manage  the  evolution  steps  from  the  moment  a  system  is  proposed  until  its  comple¬ 
tion. 

5.  The  development  of  an  automated  version  control  and  configuration  management 
mechanism  which  is  transparent  to  the  users.  This  mechanism  automatically  determines 
the  version  and  variation  numbers  of  the  software  component  versions  and  decides 
which  component  version  belongs  to  which  system  configuration. 

6.  The  development  and  implementation  of  a  mechanism  for  detecting  change  conse¬ 
quences  (determine  the  components  affected  by  a  change)  to  maintain  the  global  con¬ 
sistency  of  the  design  database  and  provide  serializability  of  updates  for  each  variation. 

7.  The  developmen*  and  implementation  of  an  on-line  scheduling  algorithm  for  finding  a 
feasible  schedule  that:  meets  the  deadlines  and  precedence  constraints  of  all  the  active 
steps  or  suggests  new  deadlines  for  the  lowest  priority  deadlines  until  a  feasible  sched¬ 
ule  that  meets  the  deadlines  of  the  higher  priority  steps  is  reached.  This  algorithm  also: 

a.  Supports  teamwork  by  concurrently  assigning  ready  steps  to  available  designers. 

b.  Supports  incremental  replanning  as  additional  information  becomes  available. 

c.  Minimizes  wasted  design  effort  due  to  reorganization  of  the  schedule  as  well  as 
workers  forced  to  wait  for  completion  of  sub-tasks  via  the  immediate  detection 
of  new  dependencies  forced  by  this  reorganization  and  the  suspension  and 
rescheduling  of  the  affected  assigned-steps. 

G.  ORGANIZATION  OF  CHAPTERS 

The  rest  of  this  dissertation  is  organized  as  follows:  Chapter  II  provides  an  overview 

of  significant  related  research.  Requirement  analysis  of  the  proposed  system  is  given  in 

Chapter  ni.  Chapter  IV  discusses  the  design  and  development  of  the  proposed  evolution 

control  system  and  our  heuristic  algorithm  for  scheduling  the  evolution  steps  as  well  as  the 

algorithms  for  the  rest  of  the  system  functions.  The  evaluation  and  validation  of  the 

proposed  system  is  presented  in  Chapter  V.  Chapter  VI  includes  the  concluding  remarks. 

evaluates  the  contribution  of  the  dissertation,  and  provides  directions  for  future  work. 
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II.  SURVEY  OF  RELEVANT  WORK 


A.  OVERVIEW 

The  main  areas  in  software  engineering  relevant  to  ECS  are  software  development/ 
evolution,  version  control  and  configuration  management,  task  planning  and  scheduling, 
and  concurrency  control.  As  defined  in  Chapter  I.  the  ECS  has  two  main  functions.  The  first 
is  to  control  and  manage  the  evolving  software  system  components  which  is  directly  related 
to  the  area  of  version  control  and  configuration  management.  VCCM.  The  second  is  to 
control  and  coordinate  the  evolution  team  interactions  that  include  coordinating  their 
simultaneous  access  to  the  changing  software  components  with  the  required  concurrency 
control  to  guarantee  system  integrity,  and  coordinating  and  assigning  their  tasks  in  such  a 
way  that  maximizes  the  concurrent  assignment  and  meets  management  constraints  such  as 
deadlines  and  precedences. 

B.  REVIEW  OF  FORMAL  EVOLUTION  MODELS 

In  [52],  Luqi  presents  a  graph  model  for  software  evolution  that  introduced  the  notion 
of  evolution  step  as  the  activities  of  initiation  analysis  and  implementation  of  one  request 
for  change  in  the  system  under  evolution.  Luqi  models  the  software  system  evolution 
history  as  an  acyclic  bipartite  graph  G  » (C.  S,  1, 0}.  C  nodes  represent  system  components 
and  S  nodes  represent  evolution  steps.  The  input  edges  I  represent  the  relation  between  a 
step  and  the  set  of  system  components  that  have  to  be  examined  to  produce  output 
components  which  are  consistent  with  the  rest  of  the  system.  The  output  edges  O  represent 
the  relation  between  an  evolution  step  and  the  components  it  produces.  The  states  of  an 
evolution  steps  as  well  as  the  generation  of  substeps  to  propagate  the  change  consequences 
are  also  defined.  In  this  dissertation  we  extend  this  graph  model  to  include  other  relations 
among  system  components  (“part_of’  and  “used_by”)  and  the  “part_of’  relationship 
between  composite  step  and  its  substeps.  Details  of  the  graph  model  for  software  evolution 
and  its  extensions  are  presented  in  Chapter  in. A  as  it  is  the  basis  for  our  system. 
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FIGURE  1.  Waterfall  model 


The  waterfall  model  as  depicted  in  Figure  1  is  a  software  !*fe  cycle  model  that  covers 
the  period  from  conception  to  retirement  of  a  given  software  system.  It  is  clear  from  Figure 
1  that  the  evolution  (maintenance)  activities  follow  similar  sequence  of  steps  like  those  in 
the  development  Unlike  the  original  development  cycle,  the  evolution  activities  (adaptive, 
corrective,  and  perfective  maintenance)  must  take  into  consideration  the  existing  system’s 
requirements,  decomposition,  constraints,  capabilities  and  performance.  The  effect  of  the 
changes  must  be  propagated  to  preserve  system  consistency.  In  the  mean  time,  concurrent 
changes  must  be  coordinated  to  avoid  rollbacks  and  wasting  engineering  effort  Evolution 
changes  must  be  planned  so  that  they  meet  the  management  constraints  such  as  deadlines, 
precedence,  and  priorities.  Tbis  indicates  the  need  for  an  evolution  control  system  that  takes 
into  account  the  special  characteristics  of  the  evolution  (maintenance)  phase  of  the  software 
life  cycle  process  that  account  for  up  to  75%  of  the  cost  of  the  software  systems  [7 1  ]. 

The  evolutionary  prototyping  model,  where  a  prototype  evolves  via  a  number  of 
versions  to  the  futal  system  is  shown  in  Figure  2.  Under  this  evolution  model,  developers 
start  evolving  the  software  system  from  its  fundamental  concepts,  then  keep  modifying  the 
system  in  an  interactive  way  with  the  customer  until  the  system  reflects  the  customer’s  real 
needs.  The  importance  of  an  evolution  control  system  in  such  an  interactive,  exploratory 
system  development  model  is  even  more  obvious  than  for  the  waterfall  model.  In  this 
model  all  kinds  of  changes  are  going  on  simultaneously,  corrective  changes  to  reflect  the 
real  customer  requirements  after  reviewing  the  designer’s  interpretation  of  portions  of  the 


devclopr'^  requirements,  adaptive  changes  to  the  rest  of  the  customer’s  real  needs,  and 
perfective  changes  to  the  fundamental  concepts  already  accepted  by  the  customers.  The 
interactions  between  these  different  activities,  the  coordination  among  related  ones, 
propagating  the  effects  of  each  of  these  changes  to  the  rest  of  the  developed  modules,  and 
keeping  track  of  which  component  belongs  to  which  system  version  are  the  main  goals  of 
our  evolution  control  system. 


FIGURE  2.  Rapid  Prototyping  Model 

C.  VERSION  CONTROL  AND  CONFIGURATION  MANAGEMENT 

As  indicated  in  [81],  version  control  and  configuration  management  is  one  of  the  fields 
in  software  engineering  that  has  received  much  discussion  and  many  proposals  for  proper 
version  and  configuration  models  in  different  domains,  but  little  has  been  implemented. 
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and  much  remains  to  be  done  in  developing  techniques  for  ensuring  the  consistency  of 
configurations  and  space  efficient  algorithms  for  version  management. 

According  to  (47)  and  [26],  representations  of  the  versioning  process  can  be  classified 
into  two  main  models.  The  first  model  is  the  conventional  Version  Oriented  Model  (VOM) 
in  which  a  system  is  divided  into  modules  each  of  which  is  versioned  independently  from 
the  other  modules.  To  configure  a  system  one  has  to  select  a  version  of  each  module  of  the 
system.  This  makes  version  a  primary  concept  while  change  is  a  secondary  concept  as  a 
difference  between  versions.  Both  SCCS  and  RCS  (75)  (76)  [78]  conform  to  this  model. 
The  second  model  is  the  Change  Oriented  Model  (COM).  In  this  model  the  functional 
change  is  the  primary  concept.  Versions  are  identified  by  a  characteristic  set  of  functional 
changes.  To  configure  a  system  in  this  model,  one  has  to  select  a  iet  of  mutually  compatible 
functional  changes.  Versions  in  this  model  are  global,  meaning  that  to  examine  a  module 
one  has  to  specify  a  single  version  of  the  system  first,  then  proceed  to  the  required  module. 
The  Aide*'de'-camp  software  management  system  [1]  belongs  to  this  model.  On  the  other 
hand,  in  a  VOM  system,  to  examine  a  module  one  has  to  select  the  module  first,  then 
individually  select  which  version  of  this  module  is  the  target. 

Reference  (26)  also  defines  two  more  models:  The  composition  model  and  the  long 
transaction  model.  The  composition  model  is  a  natural  outgrowth  of  the  VOM  model.  A 
configuration  in  this  model  consists  of  a  system  model  and  version  selection  rules.  A 
system  model  lists  all  the  components  of  a  system.  Version  selection  rules  define  which 
version  is  to  be  selected  for  each  component  to  compose  a  configuration  rather  than 
allowing  the  user  to  manually  pick  component  versions.  Selection  rules  may  be  specific, 
i.e.,  repeated  application  of  the  selection  rules  will  result  in  the  same  component  versions 
(bound  configuration).  Otherwise  the  selection  rules  are  generic  (partially  bound  or 
configuration  template),  i.e.,  application  of  the  rules  at  different  times  may  result  in  a 
different  bound  configuration,  e.g.,  choosing  the  latest  version. 

The  long  transaction  model  supports  the  evolution  of  whole  systems  as  a  sequence  of 
apparently  atomic  changes,  and  coordinates  the  change  of  software  systems  by  teams  of 
developers.  Developers  work  primarily  with  configurat'  ^.s  rather  than  individual 
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components.  A  change  is  performed  in  a  transaction.  A  specific  configuration  is  selected  as 
a  starting  point  for  changes  which  implicitly  determines  the  version  of  the  components.  The 
modifications  to  this  configuration  are  not  visible  outside  the  transaction  until  the 
transaction  is  committed.  Multiple  transactions  are  coordinated  via  concurrency  control 
schemes  to  guarantee  no  loss  of  changes.  The  result  of  the  committing  of  a  transaction  is  a 
new  system  configuration  version  either  on  the  same  development  path  or  branch  from  an 
existing  development  path  resulting  in  a  new  alternative  (variation)  development  path. 

Our  work  utilizes  concepts  from  both  the  VOM  and  long  transaction  models.  Applying 
a  top  level  evolution  step  to  a  base  version  of  a  software  system  leads  to  versioning  of  both 
the  individual  components  involved  in  the  change  and  the  entire  software  system  producing 
a  new  configuration  version  (version  of  a  whole  system).  In  addition  our  system 
automatically  coordinates  teamwork  in  such  a  way  that  concurrency  control  is  done  at  a 
higher  level  of  abstraction,  i.e.,  the  serialization  of  dependent  evolution  steps  is  done  by 
serializing  their  assignment  to  developers  in  the  same  order  and  excluding  the  need  for  the 
traditional  locking  schemes.  Including  the  evolution  steps,  with  all  the  data  they  have  about 
the  change  they  implement,  as  nodes  in  the  bipartite  evolution  history  graph  facilitates 
evolution  history  tracing. 

The  three  main  aspects  of  organizing  software  objects  defined  in  [31 ): 

1.  evolution:  The  software  objects  should  be  organized  in  such  a  way  that  makes  it  possi¬ 
ble  to  view  their  evolution  and  origin. 

2.  membership:  grouping  software  objects  in  a  way  that  they  are  easy  to  find,  and 

3.  composition:  putting  the  appropriate  components  together  for  the  composition  of  a  new 
release, 

are  similar  to  the  underlying  concepts  used  by  our  mechanism;  the  difference  is  that  we  use 
composit  objects  to  represent  the  membership  organization  and  to  define  the  composition 
organization.  This  same  structure  represents  configurations  of  systems  and  their 
subsystems. 

Our  concept  of  composite  entities  and  its  generalization  to  fit  system  configurations  is 
also  similar  to  that  used  in  PACT  [70].  Our  system  uses  a  computed  labeling  function  and 
a  single  versioning  mechanism  for  automatically  versioning  individual  objects  as  well  as 
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configuring  a  system  (as  a  composite  object).  Simplifying  version  control  and 
configuration  management  and  making  it  transparent  to  the  user  without  requiring  hivher 
intervention,  as  it  is  the  case  in  our  system,  are  two  of  the  main  goals  of  a  good  version 
control  and  configuration  management  system  as  set  forth  by  Feldman  in  (27]. 

Our  system  takes  care  of  planning,  scheduling,  status  accounting  and  auditing  of 
changes  via  explicit  representations  of  steps  as  well  as  software  component  versions.  Each 
step  has  a  unique  step  number  (generated  automatically  by  the  system)  and  is  associated 
with  all  the  relevant  information  such  as  dependent  modules,  affected  modules,  who  made 
the  changes  and  when,  and  the  cunent  status  of  the  step  in  addition  to  a  description  of  the 
motivation  for  these  changes.  This  enables  the  system  to  answer  questions  similar  to  those 
mentioned  in  [49]  such  as:  what  changes  were  made  in  step  #X,  what  components  were 
affected  by  this  change,  what  changes  were  made  to  the  system  after  a  certain  date,  and  so 
on. 

D.  TOOL  SUPPORT  FOR  CONFIGURATION  MANAGEMENT  AND 
COOPERATIVE  DESIGN 

According  to  Kaiser  and  Perry  (37]  the  main  tools  that  propagate  changes  among 
modules  are  listed  below.  However,  none  of  these  support  the  enforced  model  of 
cooperation  among  programmers  necessary  for  large  maintenance/evoludon  projects  or 
automatically  assign  tasks  to  programmers: 

Make:  a  UNIX  tool  that  rebuilds  the  entire  software  system.  It  invokes  the  tools 
specified  in  the  “Makefile”  on  changed  files  and  their  dependent  files.  Make  is  used  for 
regenerating  up-to-date  executables  after  source  objects  have  been  changed. 

Build:  is  an  extension  to  make  that  piermit  various  users  to  have  different  views  of 
target  software  system.  A  “viewpath”  defines  a  series  of  directoncs  to  be  searched  by  make 
to  locate  the  files  listed  in  the  makefile. 

Cedar:  the  Cedar  System  Modeler  uses  an  advanced  version  of  the  Make  tool  with 
version  control  to  invoke  the  tools  on  a  specific  versions  of  files.  This  System  informs  the 
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“Release  Master”,  a  programmer,  about  any  syntactic  interface  errors.  The  Release  Master 
is  responsible  for  making  work  arrangements  w-th  responsible  programmers. 

DSEE:  the  Apollo  Domain  Software  Engineering  Environment  also  uses  a  Make-like 
tool  with  version  control.  DSEE  also  has  a  monitoring  facility  that  permits  programmers 
and/or  managers  to  request  to  be  notified  when  certain  modules  are  changed. 

Masterscope:  Interlisp’s  Masterscope  tool  maintains  cross-reference  information 
between  program  units  automatically.  It  also  approximates  change  analysis  of  potential 
interference  between  changes  by  answering  queries  about  syntactic  dependencies  among 
program  units. 

SVCE:  the  Gandalf  System  Version  Control  Environment  performs  incremental 
consistency  checking  across  the  modules  in  its  database  and  nodfies  the  programmer  of 
errors  as  soon  as  they  occur.  The  consistency  checking  is  limited  to  synuctic  interface 
errors.  It  supports  multiple  programmers  working  in  sequence  but  does  not  handle 
simultaneous  changes. 

Kaiser  and  Perry  (37]  (38]  (65)  also  describe  Infuse,  a  system  that  automates  change 
management  by  enforcing  programmer  cooperation  to  maintain  consistency  among  a 
sequence  of  scheduled  source  code  changes.  Infuse  automatically  partitions  these  modules 
into  a  hierarchy  of  experimental  databases.  This  partitioning  may  be  done  according  to  the 
syntactic  and/or  semantic  dependencies  among  the  modules  or  according  to  project 
management  decision.  Each  experimental  database  provides  a  forum  for  the  programmers 
assigned  to  its  modules  or  their  managers,  and  provides  also  for  consistency  checking 
among  those  modules  (meaning  that  the  interface  between  the  modules  must  be  correct  and 
that  the  modules  can  compile  and  link  successfully).  Consistency  checking  among  the 
experimental  database  modules  is  a  pre-condition  for  merging  a  database  back  to  its  parent 
experimental  database.  Infuse  automatically  partitions  the  database  into  experimental 
databases  but  programmers  are  assigned  to  the  these  databases  manually. 

In  our  system  tasks  and  copies  of  the  associated  versions  of  software  components  are 
assigned  automatically  to  designers  (programmers)  according  to  their  dependencies. 
Versions  are  generated  automatically  as  soon  as  the  work  is  done.  Syntactic  and  semantic 
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consistency  checking  for  source  code  can  be  implemented  by  associating  declarations  of 
consistency  constraints  with  steps,  and  triggering  the  required  checking  actions  as  pan  of 
the  commit  protocol. 

E.  APPROACHES  TO  SCHEDULING  EVOLUTION  STEPS 

A  scheduling  problem  in  a  real-time  system  is  described  by  three  basic  concepts;  the 
model  of  the  system,  the  characteristics  of  the  tasks  to  be  .scheduled,  and  the  objective  of 
the  scheduling  algorithm  [67]. 

First,  the  system  model  in  our  case  consists  of  a  set  of  m  designers  D  =  { d  | .  d2. ...  d,n )  ■ 
Those  designers  arc  of  three  different  expertise  levels  [low,  medium,  high).  The 
scheduling  algorithm  determines  the  order  of  the  execution  of  tasks  by  each  designer  in 
such  a  way  that  resource,  precedence,  and  timing  constraints  are  met.  In  our  system 
resources  required  by  a  task  other  than  the  designer  resources  are  assumed  to  be  available 
as  soon  as  the  task  is  assigned. 

Second,  the  nature  of  a  task,  an  evolution  step  in  our  case,  is  characterized  by  its  timing 
constraints,  precedence  constraints,  and  resource  requirements.  The  timing  constraints  of  a 
task  are  generally  defined  in  terms  of  one  or  more  of  the  following  parameters  [67]: 

1 .  The  anival  time,  T^:  The  time  at  which  a  task  arrives  at  the  system. 

2.  The  earliest  start  time,  Test-  The  earliest  time  at  wh'ch  a  task  can  start  execution, 
(invariant:  ^esi  -  Ti)- 

3.  The  worst  case  execution  time,  T^;  The  execution  time  of  a  task  is  always  less  than  this 
time. 

4.  The  deadline,  T,j:  The  time  by  which  a  task  must  be  completed. 

The  following  invariant  is  always  true:  0  ^  Ta  ^  Test  ^  ^”(1  * 

While  all  the  tasks  and  their  timing  constraints  are  known  beforehand  in  a  static 
system,  tasks  arrive  at  arbitrary  times  in  a  dynamic  system,  so  that  the  number  of  tasks  to 
be  scheduled  as  well  as  their  arrival  times  are  unpredictable. 

In  many  conventional  real-time  systems  a  fixed  priority  is  assigned  to  each  task  to 
reflect  the  criticalness  of  the  deadlines,  and  tasks  are  executed  in  an  order  determined  by 
their  priorities.  These  priorities  are  adjusted  (manually),  during  the  testing  period,  until  the 
system  designer  is  convinced  that  the  system  works.  This  approach  works  only  for 
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relatively  simple  systems,  because  of  the  difficulty  of  determining  a  good  priority 
assignment  for  a  system  with  a  large  number  of  tasks  by  such  a  test-and-adjust  method. 
Also,  once  the  priorities  are  fixed  on  a  system,  it  is  very  expensive  to  modify  the  priority 
assignment  [67].  Often,  priorities  are  assigned  to  tasks  based  only  on  their  importance, 
without  a  complete  analysis  of  how  these  priority  assignments  will  affect  the  timing 
characterisdes  of  other  tasks.  Using  priorities  in  this  way  make  it  more  difficult  to  satisfy 
dming  constraints  of  all  the  tasks  [83]. 

The  relations  between  the  tasks  are  determined  by  the  precedence  constraints  among 
these  tasks.  If  a  task  Ti  must  be  completed  before  another  task  Tj  can  be  started  then  we  say 
Tj  precedes  Tj.  The  precedence  graph  of  a  set  of  tasks  is  a  directed  acyclic  graph.  This 
precedence  graph  is  known  in  advance  in  stauc  systems.  In  dynamic  systems  where  new 
sets  of  interrelated  tasks  arrive  arbitrarily,  the  precedence  graph  is  known  only  when  the 
task  set  arrives. 

Third,  the  objeedve  of  an  algorithm  for  scheduling  a  set  of  tasks  is  to  determine 
whether  there  exists  a  schedule  for  execuung  the  tasks  that  sadsfies  the  timing,  precedence, 
and  resource  constraints,  and  to  calculate  such  a  schedule  if  one  exists. 

Task  scheduling  in  real-time  systems  can  be  static  or  dynamic.  A  static  approach 
performs  the  calculation  of  the  schedules  for  tasks  off-line.  It  requires  prior  knowledge  of 
the  characteristics  of  the  tasks.  On  the  other  hand,  a  dynamic  approach  calculates  schedules 
for  tasks  “on  the  fly”.  Despite  the  fact  that  static  approaches  have  low  run-time  cost,  they 
are  inflexible  and  cannot  respond  to  a  changing  environment  with  unpredictable  behavior. 
This  inflexibility  leads  to  calculating  the  schedule  for  the  whole  system  when  a  new  tasks 
are  added,  which  is  expensive  in  terms  of  both  time  and  cost.  In  contrast,  dynamic 
approaches  involve  higher  run-time  costs,  but  they  arc  flexible  to  adapt  to  environment 
changes.  A  survey  of  static  and  dynamic  scheduling  approaches  can  be  found  in  [67]. 

Task  scheduling  can  also  be  characterized  as  preemptive  and  nonpreemptive.  A  task 
is  preemptive  if  its  execution  can  be  interrupted  by  other  tasks  and  resumed  afterwards.  A 
task  is  nonpreemptive  if  it  must  run  to  completion  once  it  starts. 
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1.  Scheduling  Tasks  with  Precedence  Constraints 

Scheduling  tasks  with  arbitrary  precedence  constraints  and  unit  computation  time 
in  multiprocessor  systems  is  NP-hard  for  both  the  preemptive  and  nonprcemptivc  cases 
[67]  [84].  Scheduling  nonpreemptive  tasks  with  arbitrary  ready  times  is  NP-hard  in  both 
multiprocessor  and  uniprocessor  systems  [67]  [83]  which  excludes  the  possibility  of  the 
existence  of  a  polynomial  time  algorithm  for  solving  the  problem.  Hong  and  Leung  [34] 
proved  that  there  is  no  optimal  on-line  scheduler  can  exist  for  task  systems  that  have  two 
or  more  distinct  deadlines  when  scheduled  on  m  identical  processors  where  m  >  1 . 

Scheduling  evolution  steps  to  more  than  one  designer  with  arbitrary  precedence 
constraints  and  arbitrary  deadlines  is  the  same  problem  as  that  of  multiprocessor  scheduling 
mentioned  above  which  is  shown  by  many  researchers  to  be  NP-hard.  These  negative 
results  dictate  the  need  for  heurisdc  approaches  to  solve  scheduling  problems  in  such 
systems.  In  the  rest  of  this  section  we  review  some  of  the  relevant  task  scheduling  heuristics 
used  in  similar  problems  and  highlight  their  relevance  iO  our  work. 

In  [72]  Stankovic  et  al.  present  an  O  (n^)  heuristic  scheduling  algorithm  for 
scheduling  a  set  of  independent  processes  on  a  set  of  identical  processors.  A  task  (process) 
in  this  model  is  characterized  by  an  arrival  time  T^,  a  deadline  Tq,  a  worst  case 
computation  time  T^^,  and  a  set  of  resource  requirements  { } .  Tasks  are  independent,  non 
periodic  and  non-preempdve.  The  authors  stated  that  scheduling  a  set  of  tasks  to  find  a  full 
feasible  schedule  is  a  search  problem  with  a  search  tree  as  the  search  space.  The  scheduling 
algorithm  starts  at  the  root  of  the  tree  which  is  an  empty  schedule.  It  tries  to  extend  the 
schedule  by  moving  to  the  one  of  the  nodes  in  the  next  level  of  the  search  tree  until  it 
reaches  a  full  feasible  schedule.  It  is  worth  nodng  that,  during  the  expansion  of  the 
schedule,  an  intermediate  node  is  a  partial  schedule,  while  leaf  nodes  (terminal  node) 
represent  full  schedules.  It  is  clear  that  not  every  terminal  node  corresponds  to  a  feasible 
schedule.  To  extend  the  schedule  to  a  node  of  the  next  level  of  the  search  tree,  the  algorithm 
uses  a  boolean  funedon  called  “strongly-feasiblc"  to  determine  if  the  partial  schedule  is 
strongly-feasible  or  not.  A  partial  schedule  is  strongly-feasible  if  all  schedules  reached  by 
extending  it  by  each  of  the  remaining  tasks  are  also  feasible.  This  means  that  if  a  partial 
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feasible  schedule  is  found  not  to  be  strongiy-feasible  because  a  task  T  misses  its  deadline, 
then  the  search  should  stop  on  this  path  since  none  of  the  future  extensions  of  task  T  will 
meet  its  deadline.  However,  it  is  possible  to  backtrack  to  continue  the  search  in  such  cases. 
After  deciding  that  a  partial  schedule  is  strongiy-feasible,  a  heuristic  function  (H)  is  used 
to  direct  the  search  to  a  plausible  path. 

This  algorithm  works  as  follows:  Given  a  particular  heuristic  function  H.  the 
algorithm  begins  with  an  empty  partial  schedule.  Every  step  of  the  algorithm  includes  (a) 
determining  if  the  current  partial  schedule  is  strongiy-feasible,  and  if  so  (b)  extending  the 
current  partial  schedule  by  one  task.  This  task  is  selected  by  applying  the  H  function  to  all 
the  tasks  remaining  to  be  scheduled  and  determining  the  one  with  the  minimum  H  value. 

Some  of  the  H  functions  used  in  [72]  are  Minimum  deadline  first(Min_D), 
Minimum  processing  time  first  (Min_P).  Minimum  earliest  start  time  first  (Min_S), 
Minimum  laxity  firr*  (Min_L),  and  the  combinations  (Min_D  +  Min_P)  and  (Min_D  + 
Min_S). 

In  [67],  Ramamritham  et  ai.  introduce  an  0(nk)  version  of  the  algorithm 
introduced  in  [72]  by  considering  only  k  tasks  of  the  remaining  tasks  to  be  scheduled  for 
applying  the  H  function  and  evaluating  the  strongiy-feasible  function. 

Both  [72]  and  [67]  use  a  vector  data  structure  for  each  type  of  resources  to 
maintain  the  earliest  available  time  for  each  resource  of  each  type.  In  our  algorithm  for 
scheduling  evolution  steps  we  extend  this  algorithm  to  handle  the  case  where  there  are 
precedence  constraints  between  pairs  of  steps,  and  keep  a  vector  of  earliest  available  times 
of  designers  for  each  expertise  level.  Details  of  our  algorithm  are  in  Chapter  IV.C 

In  [82],  Xu  and  Pamas  present  a  pre-run  time  (static)  algorithm  to  find  a  feasible 
schedule  if  one  exists  on  a  single  processor  for  a  set  of  processes  with  arbitrary  precedence 
and  exclusion  relations  and  arbitrary  deadlines.  This  algorithm  assumes  that  release  times, 
deadlines,  precedence  and  exclusion  relations  are  known  in  advance. 

In  [84],  Xu  and  Pamas  extend  their  pre-run  time  algorithm  presented  in  [82] 
above  to  find  a  feasible  nonpreemptive  schedule  whenever  one  exists  on  M  identical 
processors  for  the  same  set  of  processes  defined  above.  In  both  cases  the  algorithms  use  a 
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branch  and  bound  technique  that  has  a  search  tree  where  at  its  root  node  they  use  an  earliest 
start  time  fust  strategy  to  compute  a  schedule  called  the  “valid  initial  solution"  that  satisfies 
the  release  time  constraints  and  all  of  the  initial  precedence  and  exclusion  relations.  For 
each  node  in  the  search  tree  a  lower  bound  on  the  lateness  of  any  schedule  leading  from  that 
node  is  computed.  The  algorithm  branches  from  the  node  that  has  the  least  lower  bound 
among  all  unexpanded  nodes.  This  operation  continues  until  either  a  feasible  solution  is 
found  or  there  exist  no  unexpanded  node  that  has  a  lower  bound  less  than  the  least  lateness 
of  all  valid  initial  solutions  found  so  far.  Tliis  algorithm  requires  all  the  constraints  to  be 
known  in  advance  which  is  not  the  case  in  our  problem.  It  also  does  not  provide  any 
response  to  changing  any  of  the  constraints  of  the  task  set  or  the  arrival  of  new  tasks. 
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III.  REQUIREMENTS  ANALYSIS 

A.  GOALS  AND  JUSTinCATIONS 

The  main  goal  of  this  dissertation  is  to  develop  a  model  and  algorithm  for  an  evolution 
control  system  (ECS)  for  the  software  evolution/prototyping  process.  This  system  provides 
automated  support  for  changes  in  plan  during  the  execution  of  the  plan  and  automatic 
decision  support  for  planning  and  team  coordination  based  on  design  dependencies 
captured  in  a  configuration  model.  This  ECS  is  needed  to  control  and  coordinate  the 
overwhelming  changes  dictated  by  the  evolutionary  nature  of  the  software  prototyping/ 
development  process.  These  prototypes  experience  iterative  and  exploratory  modifications 
through  large  numbers  of  versions  and  variations  to  cope  with  customers'  changing  and 
growing  needs.  Coordination  is  needed  to  avoid  rollbaclts,  redundancy  and  inconsistency. 
Control  is  a  necessity  for  managing  both  the  design  data  (version/configuration  control)  and 
the  design  team  via  orchestrating  task  assignment  to  support  management  policies.  This 
allows  the  software  development  team  to  concentrate  on  what  is  needed  to  fix  or  improve 
system  components  rather  than  worrying  about  managing  this  enormous  amount  of  data. 
The  following  a*-*,  the  main  goals  for  our  proposed  system; 

1.  Manage  the  evolution  steps  from  the  moment  a  system  is  proposed  until  its  completion. 

2.  Reach  a  feasible  schedule  that  meets  the  deadline  requirements  of  all  the  active  steps  or 
automatically  cancel  the  lowest  priority  deadlines  until  a  feasible  schedule  that  meets 
the  deadlines  of  the  higher  priority  steps  is  reached. 

3.  Support  teamwork  by  identifying  the  steps  that  can  be  scheduled  concurrently. 

4.  Support  incremental  replanning  as  additional  information  becomes  available. 

5.  Minimize  wasted  design  effort  due  to  reorganization  of  the  schedule  as  well  as  workers 
forced  to  wait  for  completion  of  sub-tasks  via  the  inunediate  detection  of  new  depen¬ 
dencies  forced  by  this  reorganization  and  the  suspension  and  rescheduling  of  any  of  the 
affected  assigned- steps. 

6.  Ensure  system  integrity  via  propagating  change  consequences  (induced  steps)  to  main¬ 
tain  the  global  consistency  of  the  design  database  and  provide  serializability  of  updates. 

7.  Provide  automated  version  control  and  configuration  management. 

8.  Efficient  use  of  space  and  time  for  the  design  database  and  scheduling  algorithm. 
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The  first  goal  is  needed  to  help  the  prototype  manager  control  the  large  number  of 
changes  dictated  by  both  the  exploratory  nature  of  the  prototyping  process  and  customer 
feedback,  and  keep  track  of  which  designer  is  performing  which  change.  The  second  goal 
is  crucial  for  planning  to  accomplish  the  required  changes.  The  third  and  fourth  goals  are 
to  cope  with  the  dynamics  of  the  prototyping  process  where  the  steps  to  be  scheduled  are 
only  partially  known.  Tune  required,  the  set  of  sub-tasks  for  each  step,  and  the  input/output 
constraints  between  steps  are  all  uncertain  and  subject  to  change  as  evolution  steps  are 
carried  out.  The  global  consistency  of  the  design  database  is  covered  by  the  fifth  goal.  The 
sixth  goal  seeks  to  automate  the  version  control  and  configuration  management  in  this 
dynamic  environment  to  save  designers’  time  and  effort  They  need  not  worry  about 
managing  the  complicated  design  database  and  may  concentrate  on  their  main  task  of 
performing  the  required  tasks.  The  last  goal  is  an  implementation  requirement  for  saving 
storage  space,  especially  in  this  exploratory  environment  where  many  alternatives  are 
explored  that  require  much  storage  space,  and  to  find  a  time-efftcient  scheduling  algorithm 
that  does  not  impact  the  timing  constraints  of  the  scheduled  steps. 

B.  GRAPH  MODEL  OF  SOFTWARE  EVOLUTION 

Since  the  main  purpose  of  the  ECS  is  managing  software  evolution  in  a  rapidly 
evolving  system,  we  review  a  graph  model  of  software  evolution  that  constitutes  the 
context  for  building  the  ECS  {52]  [58].  The  goal  of  this  model  is  to  provide  a  framework 
for  integrating  software  evolution  activities  with  configuration  control  [52].  The  model  of 
software  evolution  has  two  main  elements:  system  components  and  evolution  steps.  System 
components  are  immutable  versions  of  software  source  objects  that  cannot  be  reconstructed 
automatically.  Evolution  steps  are  changes  to  system  components  that  have  the  following 
properties  in  the  original  version  of  the  graph  model  [52]: 

1.  A  top-level  evolution  step  represents  the  activities  of  initiation,  analysis,  and  imple¬ 
mentation  of  one  change  request. 

2.  An  evolution  step  may  be  either  atomic  or  composite. 

3.  An  atomic  step  produces  at  most  one  new  version  of  a  system  component.  This  prop¬ 
erty  is  no  longer  true  in  our  model  in  order  to  include  the  cases  in  which  an  atomic  step 
is  applied  to  an  originally  atomic  component  that  needs  to  be  decomposed  according  to 


19 


some  design  considerations.  This  decomposition  may  lead  to  the  production  of  more 
than  one  componentThis  modification  is  illustrated  in  section  C.2.e  later  in  this  chap¬ 
ter. 

4.  The  hputs  and  outputs  of  a  composite  step  correspond  to  the  inputs  and  outputs  of  its 
substeps. 

5.  The  model  allows  steps  that  do  not  lead  to  the  production  of  new  configurations,  e.g. 
design  alternatives  that  were  explored  but  not  included  in  the  configuration  repository. 

6.  Completely  automatic  transformations  are  not  considered  to  be  steps  and  are  not  con^ 
sidered  in  this  model. 

7.  The  graph  model  can  cover  multiple  systems  which  share  components,  alternative  vari¬ 
ations  of  a  single  system,  and  a  series  of  configurations  representing  the  evolution  his¬ 
tory  of  each  alternative  variation  of  a  system. 

8.  A  scope  is  associated  with  each  evolution  step  which  identifies  the  set  of  systems  and 
variations  to  be  affected  by  the  step.  The  scope  is  used  to  determine  which  induced  evo¬ 
lution  steps  are  implied  by  a  change  request. 

The  evolution  history  is  modeled  as  a  graph  Cs:[C,  S.  CE.  SE.  I,  O).  This  graph  is  a 
directed  acyclic  graph  (bipartite  with  respect  to  the  edges  I  and  O).  C  and  S  are  the  two 
kinds  of  nodes  (C:  software  component  nodes,  and  S:  evolution  step  nodes  respectively). 
Each  node  has  a  unique  idenUfier.  C  and  S  nodes  alternate  in  each  path  that  has  only  I  and 
O  edges.  This  represents  the  evolution  history  view  of  the  graph.  The  edges  represent  the 
“part_of’  (between  a  sub-component  of  a  composite  component  and  the  composite 
component)  and  “used_by”  relations  (defined  between  components  to  represent  the 
situation  where  the  semantics  or  implementation  of  one  component  A  depends  on  another 
component  B;  B  used_by  A)  between  the  software  components  of  a  given  configuration 
(  CE  C  C  X  C),  the  ‘‘part_of  ’  relation  between  a  substep  of  a  composite  step  and  the 
composite  step  (  S£  c  5  x  S  ),  the  input  relation  between  the  system  components  which 
must  be  examined  to  produce  output  components  that  are  consistent  with  the  rest  of  the 
system  and  the  corresponding  evolution  stcps(/  c  C  x  5),  and  output  relation  between 
evolution  steps  and  the  components  they  produce  (O  c  S  x  C).  System  components  are 
immutable  versions  of  software  source  objects  that  cannot  be  reconstructed  automatically. 

An  “edge_type”  attribute  is  used  to  distinguish  between  the  two  kinds  of  edges 
representing  the  relations  “uscd_by"  and  “part_of’  defined  on  the  set  of  edges 
CE  c  C  X  C.  The  “used_by”  relation  can  be  used  for  automatic  identification  of  inputs  of 
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proposed  evolution  steps  and  identification  of  the  induced  steps  triggered  by  a  proposed 
step.  A  review  of  the  formal  definitions  of  some  of  the  concepts  mentioned  above,  as 
defined  in  the  original  grap'.i  model  [52],  is  introduced  below.  Some  modifications  to  some 
of  these  definitions  and  the  reasons  for  them  are  indicated  where  it  takes  place. 

a)  the  set  of  input  components  of  a  step:  input  (s:  $)»  (c:  Cl  (c.  s]  €  1 )  ( 1 ) 

b)  the  set  of  output  components  of  a  step:  output  (s:  S)s  {c:  Cl  [s,  c]  €  O}  (2) 

c)  Atomic  step:  atomic  (s:  S)*  -  EXISTS  (si:  S::  si  part_of  s)  (3) 

d)  one  component  affects  another  if  both  components  are  identical  or  if  the  first  is 
used  in  the  derivation  of  the  second: 

ALL(cI,  c2:C:;  cl  affects  c2  «» cl  used_by*  c2)  (4) 

where  “used_by*”  is  the  reflexive  transitive  closure  of  the  “used_by”  relation  defined 
above. 

e)  The  output  of  a  composite  step  includes  all  the  outputs  of  its  sub-steps: 

ALX(sl,  s2:S.  c:  C::  si  part^of  s2  &  c  e  output  (si)  =»  c  €  output  (s2))  (5) 

0  Every  input  to  a  sub-step  either  must  be  affected  by  some  input  to  the  parent  step, 
or  must  affect  some  output  of  the  sub-step 

ALL(sl.  s2:  S,  c:  C::  si  part.of  s2  &  cl  €  input  (si)  9 

EXISTS  (c2:  C::  c2  €  input  (s2)  &  c2  affects  cl)  I 

c2  €  output  (si)  &  cl  used_by  c2)))  (6) 

g)  The  primary  input  concept  can  be  formalized  by  introducing  the  attributes 
objectjd,  versionjd  and  variationjd  that  apply  to  versions  to  yield  a  unique  identifier  for 
the  object  and  variation  associated  with  each  version.  Variations  represent  alternative 
choices,  which  may  correspond  to  different  formulations  of  the  requirements  in  the  context 
of  prototyping,  or  different  kinds  of  system  software  (operating  system,  window  manager, 
etc.)  in  the  context  of  product  releases.  Versions  represent  the  evolution  history  of  a 
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particular  variation.  An  input  to  a  step  is  primary  if  and  oniy  if  it  is  the  previous  version  of 
the  same  object  and  belongs  to  the  same  variation  as  the  output  of  the  step.  Same  variation 
and  primary  input  concepts  are  detlned  as  follows: 

ALL(cl,  c2:C::  c  1  same-variation  c2  <=>  object-id(cl)  =  object-id  (c2)  & 

variation-id(cl)  =*  variation-id(c2))  (7) 

ALL  (s:  S,  cl;  C::  cl  primar'Jnput  s  <=> 

cl  e  input  (s)  &  EXISTS  (c2;  C:  c2  €  output  (s)  &cl  same- variation  c2)  (8) 

The  above  definition  does  not  consider  the  inputs  that  leads  to  a  new  version  of  an 
object  on  a  different  variation  (split)  as  primary  inputs.  This  is  the  reason  we  define  an  input 
to  a  step  to  be  a  primary  input  if  and  only  if  it  is  the  previous  version  of  the  same  object  as 
the  output  of  the  step.  This  concept  can  be  formalized  as  follows. 

ALL  (s:  S,  cl:  C::  cl  primary Jnput  s  <*> 

cl  €  input  (s)  &  EXISTS  (c2:  C::  c2  €  output  (s)  &  objertjd  (c2) »  objeetjd  (cl) 

&  versionjd  (c2)  =  version Jd  (cl)  +  1))  (9) 

h)  The  scope  of  a  top-level  step  consists  of  the  components  affected  by  its  inputs. 

scope(s:S) »  {cl:C  I  EXISTS  (c2:C::  c2  e  input  (top(s))  &  c2  affects  cl)l  (10) 

i)  The  set  of  induced  steps  are  defined  as  follows. 

induced-steps  (si)  »(s2:S  I  EXISTS  (cl,c2:C::  cl  primary  Jnput  si 

&  c2  primary  Jnput  s2  &  cl  affects  c2  &  cunent(c2)  &  c2  €  scope  (si))}  (11) 

where  a  component  is  current  if  there  is  no  later  version  of  the  same  variation  of  the 
same  object: 

ALL(cl:C::  current  (cl) »  -»  EXISTS(c2:C:;  cl  O'**  c2  &  cl  same_variation  c2)) 

(12) 
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where  D*  is  the  transitive  closure  of  the  relation  D  =  (1  u  O)  (13) 

1.  Summary  of  Modifications  to  the  Original  Graph  Model 

In  the  previous  section  we  have  introduced  three  basic  modifications  to  the 
original  graph  model  [52].  First,  two  sets  of  edges  are  added  to  the  original  graph  model  to 
represent  the  “pait_of  ‘  relation  (between  a  sub-component  of  a  composite  component  and 
the  composite  component)  and  “used_by”  relation  (defined  between  components  to 
represent  the  situation  where  the  semantics  or  implementation  of  one  component  A 
depends  on  another  component  B;  B  uscd_by  A)  between  the  components  of  a  given 
configuration  (  C£  c  C  x  C).  and  the  “part_of  *  relation  between  a  substep  of  a  composite 
step  and  the  composite  step  (  SEcSxS  ). 

The  second  modificadon  is  relaxing  the  restriction  on  an  atomic  step  to  produce 
at  most  one  output  component  This  modification  is  needed  to  account  for  the  cases  where 
a  designer  assigned  an  atomic  step  (atomic  steps  are  always  parts  of  a  top  level  evolution 
step  that  is  used  for  control  purposes  and  is  not  assigned  to  a  designer.  See  section  III.B.7 
for  details)  needs  to  decompose  the  assigned  module  which  may  lead  to  the  production  of 
more  than  one  output  from  the  step.  Since  the  ECS  has  control  over  the  components  in  the 
design  database,  not  over  each  designer’s  workspace,  the  designer  who  does  the 
decomposition  should  commit  these  new  modules  to  the  design  database  where  the  ECS 
can  propose  a  step  for  each  new  incomplete  subcomponent  as  parts  of  the  top  level 
evolution  step.  The  manager  reviews  the  proposed  substeps,  add  the  management 
constraints,  approve  these  substeps,  and  then  the  system  automatically  schedules  these 
substeps  to  the  rest  of  the  design  team,  supporting  teamwork. 

The  third  modification  is  changing  the  primary  input  concept  to  be  compatible 
with  the  version  control  and  configuration  model  defined  below.  An  input  to  a  step  is 
primary  if  and  only  if  it  is  the  previous  version  of  the  same  object  as  the  output  of  the  step, 
whether  the  output  version  is  on  the  same  variation  as  the  input  of  the  step  or  splitting  a  new 
variation.  This  modification  makes  some  object  versions  belong  to  one  or  more  variations 
to  help  trace  the  evolution  history  of  each  variation  to  the  initial  version  of  each  object. 
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a.  Version  and  Variation  Numbering 

As  soon  as  the  input  base  version  of  a  step  is  bound,  the  system  assigns  the 
version  and  variation  number  of  the  output  object  for  the  step.  The  variations  arc  assigned 
successive  numbers  beginning  with  1  for  the  initial  variation.  Versions  along  each  variation 
are  assigned  successive  numbers  starting  with  1  at  the  root  version  of  the  initial  variation. 
This  means  that  the  new  version  number  is  the  base  version  number  plus  one.  while  the 
variation  number  has  two  possibilities:  the  first  possibility  is  to  keep  the  base  version’s 
variation  number  at  the  time  the  step  is  assigned.  This  occurs  when  the  base  version  is  the 
most  recent  version  on  its  variation  line  at  the  time  the  step  is  assigned.  The  other 
possibility  is  to  use  the  “next”  variation  number,  which  is  the  highest  variation  number  plus 
one.  This  labeling  function  is  the  same  for  both  atomic  or  composite  objects  (the  entire 
software  system  is  represented  as  a  composite  object). 

Let  V.basel,  V_base2  be  different  versions  of  an  object  to  which  an 
evolution  step  is  applied,  and  V_new  be  the  output  version  produced  by  the  step.  Let  S  be 
the  primary  input  set  of  the  step,  then  the  version  and  variation  numbers  of  the  output 
version  of  the  step  are  calculated  as  follows: 

Case  size(S)  is: 
when  0  => 

•'  newly  created  object  starts  as  version  1  on  variation  1  of  that  object. 
version_number  (V_new)  =  1 
variation_number  (V_ncw) » 1 
when  1  => 

--  normal  case 

vcrsion_numbcr  (V_ncw)  =  version_numbcr  {V_basel)  +  1 
if  successor  (V_basel) «  none  then 

variation_number  (V_new)  =  variation_numbcr  ( V_base) 
else 

variation_number  (V_new)  »  highest_variation  (object  (V_base))  +  1 
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end  if 


when  >I  => 

-  merge  case 

if  vcrsion_numbcr  (V_basel)  >=«  version_numbcr  (V_basc2) 
then  version_number  (V_new)  =  version_number  (V_basel)  +  1 

V  =  V_basel 

else  version_number  (V_new)  ~  version_number  (V_base2)  +  1 

V  =  V_base2 

end  if 

if  successor  (v)  -  none 

then  variadon.number  (V_new) »  variation.number  (v) 

else  variation.number  (V_new)  a  highest.vahation  (object  (v))  +  1 

end  if 

where  highest.variation  is  a  function  that  returns  the  highest  variation  exist  for  an 

object 


FIGURE  3.  Variation  and  version  numbering  (case  1) 
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Cases  0  and  1,  of  this  numbering  mechanism  are  illustrated  by  an  object 
evolution  graph  in  Figure  3.  Vl.l  corresponds  to  a  newly  created  object,  VI. 2,  VI. 3  and 
VI  .4  are  examples  of  the  creation  of  versions  on  the  same  variation.  V2.2  represent  the  first 
split,  and  V3.3  represents  the  second  split  creating  the  new  variations  2  and  3  respectively. 

Case  >1,  is  included  to  make  this  numbering  system  compatible  with  the 
ongoing  work  for  automated  version  merging  capabilities  under  parallel  development  122), 
(23].  This  case  is  also  illustrated  by  an  object  evolution  graph  in  Figure  4.  V 1 .5  is  the  result 
of  merging  VI. 4  and  V2.4.  while  V3.5  is  the  result  of  merging  VI. 4  and  V2.3. 


FIGURE  4.  Variation  and  version  numbering  in  case  of  merge  (case  >1) 

This  labelir.g  function  allows  a  version  to  belong  to  more  than  one  variation 
which  is  a  necessary  modification  to  [52]  to  simplify  the  process  of  tracing  the  development 
history  of  a  version  and  to  keep  a  logical  and  realistic  development  history. 

b.  Configuration  Management 

As  mentioned  in  Section  3  above,  the  configurations  of  the  diffeient  software 
systems/prototypes  are  represented  by  a  hierarchical  structure  according  to  the  levels  of  the 
decomposition  of  each  system.  This  hierarchical  structure  is  a  directed  acyclic  graph  with 
its  nodes  representing  the  different  components  o^  the  system  and  the  edges  representing 
the  relations  among  these  components  which  are  “part-of’  and  "used_by”.  A  top  level 
evolution  step  producing  a  new  version  of  one  or  more  of  the  system  compontMs 
eventually  leads  to  producing  a  new  version  of  the  base  configuration.  This  is  done  by 
propagating  the  versioning  process  of  the  modified  components  up  the  hierarchy  from  the 
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levels  of  the  newly  created  versions  to  their  parents  and  all  the  way  up  to  the  root  of  the  tree 
which  represents  the  system  under  evolution.  It  is  worth  noting  that  the  parent  of  a  modified 
component  should  have  a  new  version  because  of  the  change  to  its  children  list  since  this 
list  should  point  to  the  new  modified  child  version.  This  is  formalized  as  follows: 

For  i=  N  down  to  2 

exists  (new-version  (component  (levcl(i))))  & 

component  (level(i))  part_of  component  (level  (i- 1 ))  & 

-1  exists  (new-version  (component  (i- 1 ))  new-version  (component  (i- 1 )) 

where  N  is  the  number  of  levels  in  the  configuration  graph  in  which  the  root  is  level  number 
1.  This  rule  is  limited  to  the  scope  of  the  step  which  is  the  base  configuration. 

Figure  S  shows  an  example  for  building  a  new  configuration  as  a  result  of 
commixing  a  top  level  evolution  step.  This  example  assumes  the  use  of  formal  specification 
in  software  evolution  that  limits  the  impact  of  evolution  steps  (i.e.,  the  implementation  of 
the  composite  modules  uses  its  own  specification  and  the  specification  of  its  sub-modules, 
but  not  the  implementation  of  the  sub-modules).  In  this  example,  the  primary  input  of  the 
step  SI  is  Oe.spec.1.1  (the  specification  of  the  module  Oe)  that  affects  its  implementation 
and  the  implementation  of  its  parent  module  Oe.imp.l.I  and  Mb.imp.1.1  respectively.  A 
substep  is  created  for  each  changing  component,  SI.l,  S1.2,  and  SI. 3  for  the  components 
Oe.spec.1.1,  Oe.imp.l.I,  and  Mb.imp.1.1. 

Committing  these  steps  after  the  modifications  are  done  will  trigger  the 
following  actions:  1 )  each  substep  produces  the  next  version  on  the  same  variation  line  of 
its  primary  input  component  (assuming  no  splits),  this  means  the  components  Oe.spec.  i  .2, 
Oe.imp.1.2,  and  Mb.imp.1.2  are  produced  as  outputs  to  the  corresponding  steps.  2)  As  a 
result  of  committing  the  three  substeps,  the  commitment  of  the  top  level  step  SI  is 
triggered.  Committing  SI  means  performing  a  Depth  First  Search  (DFS)  on  its  input 
configuration  Sys  1.2  looking  for  the  primary  input  components  of  the  step,  from  the  leaf 
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nodes  and  up,  if  a  parent  of  any  of  the  priinary  input  component  does  not  have  a  new 
version,  then  a  new  version  is  created  for  it  and  its  composition  list  is  updated  io  point  to 


FIGURE  5.  Building  a  new  configuration 
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output  edge 

part_of  &  used_by  (components) 


the  new  version  of  its  modified  child.  3)  This  versioning  of  the  parents  is  recursively  done 
for  all  the  parents  of  the  newly  created  versions  in  the  previous  step  until  the  root  node  is 
versioned  creating  the  new  configuration  Sys.1.3.  The  reason  for  performing  DFS  on  the 
primary  configuration  instead  of  just  building  the  configuration  from  the  deepest  versioned 
component  all  the  way  up  is  that  each  component  may  belong  to  more  than  one 
configuration  while  we  need  only  a  new  version  for  a  specific  one  of  them  (the  primary 
input  configuration). 

2.  States  of  Evolution  Steps 

The  dynamics  of  the  evolution  steps  are  modeled  by  associating  six  different 
states  with  each  step  to  express  the  different  activities  each  step  has  to  undergo  during  its 
lifetime.  The  state  transition  diagram  in  Figure  6  shows  the  different  explicit  decisions  that 
have  to  be  made  by  the  management  to  cause  the  transition  from  one  state  to  the  other.  It 
also  shows  the  automated  transitions  from  the  scheduled  state  to  the  assigned  state  and  vice 
versa  (explained  in  detail  in  subsections  c,  and  d  below).  By  controlling  the  states  of  the 
evolution  steps,  the  evolution  manager  exercises  direct  control  over  both  software 
evolution/development  and  the  resulting  software  configurations.  The  following  are  the 
definitions  of  those  states  and  the  corresponding  actions  that  cause  the  transition  from  one 
state  to  the  other.  These  states  are  similar  to  those  presented  in  [S2]  except  that  a  new  state 
called  “assigned”  has  been  added  for  the  reasons  explained  below. 

a.  Proposed  State 

In  this  state  a  proposed  evolution  step  is  subjected  to  both  cost  and  benefit 
analysis.  This  analysis  also  includes  identifying  the  software  objects  comprising  the  input 
set  of  the  step.  An  evolution  step  is  created  when  it  is  proposed,  which  means  that  the  initial 
status  of  a  newly  created  step  is  “proposed”.  The  create_stcp  command  takes  as  input  a 
primaryjnput  component  and  a  base  version  of  the  whole  system  configuration  and  returns 
a  unique  step  number,  a  set  of  components  affected  by  the  change  to  the  primary.input 
component  and  a  set  of  secondary  input  components  (the  components  used_by  the 
primaryjnput  component).  A  “proposed”  step  is  generally  added  to  the  configuration 
graph  as  an  isolated  step  node  that  does  not  have  any  input,  output  or  part.of  edges  (except 


when  an  old  version  is  used  that  has  existing  specific  reference).  This  is  because  the 
priniary  and  secondary  input  attributes  are  mostly  generic  inputs  (object.id  and 
variation_id  only). 


FIGURE  6.  Evolution  step’s  state  transition  diagram 

Inputs  to  an  evolution  step  can  be  specified  by  references  to  either  a  generic 
object  or  a  specific  object  version.  Generic  object  references  are  commonly  used  to  denote 
the  current  version  of  the  object  A  generic  object  reference  consists  of  an  identifier  for  the 
object  and  an  identifier  for  a  variation  of  that  object  [52].  Generic  object  references  can  be 
used  only  while  the  step  is  in  the  “proposed”,  “approved”  or  “scheduled”  states,  and  must 
be  bound  to  specific  versions  before  the  step  can  enter  the  “assigned”  state.  If  the  binding 
is  not  specified  manually,  it  defaults  to  the  version  from  the  previous  version  of  the  entire 
prototype  with  respect  to  the  serialization  order  of  the  top  level  evolution  step.  The  version 
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bindings  of  a  composite  step  are  inherited  by  its  sub-steps  to  ensure  consistency.  Specific 
object  references  are  usually  used  to  define  inputs  to  steps  in  cases  when  an  older  version 
is  used,  which  often  coincide  with  the  creation  of  new  variations. 

If  a  specifle  reference  is  to  be  used,  it  has  to  be  entered  into  the  system  by  the 
software  manager  using  the  cdit_stcp  command  before  issuing  the  schcdule_stcp 
command.  This  is  because  it  is  used  for  the  calculation  of  the  serialization  order  among  the 
steps  to  be  scheduled. 

b.  Approved  State 

In  this  state  the  implementation  of  the  step  has  been  approved  but  not 
scheduled  yet  and  the  input  set  of  the  step  is  not  bound  to  particular  versions.  Approval  of 
a  proposed  step  by  the  management  and  the  Change  Control  Board  advances  its  status  to 
“approved”,  and  triggers  the  decomposition  process  to  create  an  atomic  sub-step  for  each 
primary  or  affected  component  of  the  step.  These  sub-steps  inherit  the  status  of  their  super- 
step  which  is  “approved”  in  this  case,  and  arc  added  to  the  configuration  graph  with  a 
part.of  edge  between  each  sub-step  and  its  super  step. 

It  is  also  in  this  state  that  the  substeps  are  augmented  with  attributes  that 
include  the  estimated  duration  of  each  sub-step  and  management  scheduling  constraints 
such  as  precedence,  deadline,  and  priority.  The  “approved"  state  can  also  be  reached  from 
both  the  “scheduled”  and  “assigned”  sutes  using  the  “suspend.step”  command  to  suspend 
work  on  a  step  due  to  budget  cuts  or  other  management  reasons. 

e.  Scheduled  State 

In  this  state  the  implementation  has  been  scheduled  and  the  step  is  not  yet 
assigned  to  a  designer.  When  a  designer  is  available  the  step  is  assigned  to  him/her  and  its 
status  is  automatically  advanced  to  “assigned".  The  “scheduled”  state  is  reached  from  the 
“approved”  state  via  the  command  “schedule_step”  that  indicates  that  the  management 
constraints  are  complete  and  enables  the  scheduling  and  job  assignment  mechanisms.  The 
scheduling  mechanism  produces  an  updated  schedule  containing  the  newly  scheduled  step. 
A  schedule  specifies  the  expected  starting  and  completion  times  for  the  step.  The  scheduled 
state  can  also  be  reached  from  the  assigned  state  when  a  step  is  suspended  by  the  system 
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because  of  a  new  dependency  imposed  due  to  adding  a  new  step  to  the  schedule  or  because 
of  nuxlified  scheduling  constraints  due  to  editing  an  existing  step.  This  leads  to 
rescheduling  of  the  suspended  step. 

d.  Assigned  State 

In  this  state  the  step  is  assigned  to  the  scheduled  designer,  all  inputs  are  bound 
to  particular  versions,  and  unique  identifiers  have  been  assigned  to  its  output  components, 
but  these  components  are  not  yet  part  of  the  evolution  history  graph.  A  composite  step 
enters  the  assigned  state  whenever  any  of  its  substeps  is  assigned. 

The  assigned  state  is  reached  automatically  from  the  scheduled  state.  When  a 
designer  is  available,  the  schedule  is  used  to  determine  his/her  next  assignment  If  his/her 
next  assignment  is  ready  to  be  carried  out  then  the  step  status  is  automatically  advanced  to 
“assigned”  and  the  designer  is  informed  of  the  new  assignment  When  a  step  is  assigned, 
the  version  bindings  of  its  inputs  are  automatically  changed  from  generic  to  specific.  An 
edge  is  added  as  an  input  edge  between  the  primary  input  component  of  the  step  and  the 
step  itself  in  the  configuration  graph.  It  is  in  this  state  where  the  designer  gets  his/her 
assignment,  does  the  required  modification/development,  and  integrates  and  tests  these 
modifications  before  the  transition  to  the  final  state  “completed”. 

e.  Completed  State 

In  this  state  the  outputs  of  the  step  have  been  verified,  integrated,  and 
approved  for  release.  This  is  the  final  state  for  each  successfully  completed  step.  This  state 
can  only  be  reached  from  the  assigned  state  using  the  “commit.step”  command.  In  this 
state  the  output  components  of  the  step  have  been  added  to  the  configuration  graph.  An 
output  edge  has  also  been  added  to  the  configuration  graph  between  the  step  and  its  output 
component(s).  A  composite  step  enters  the  completed  state  when  all  of  its  substeps  arc 
completed 

f.  Abandoned  State 

In  this  state  the  step  has  been  cancelled  before  it  has  been  completed.  The 
outputs  of  the  step  do  not  appear  as  components  in  the  evolution  history  graph.  All 
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completed  work,  if  any,  of  the  step  and  the  reasons  why  the  step  is  abandoned  are  stored  as 
attributes  of  the  step  for  future  reference.  This  is  the  final  state  for  all  steps  that  were  not 
approved  by  the  management  or  cancelled  in  the  “approved”,  “scheduled”  or  “assigned” 
states. 


g.  Relation  to  the  Original  Graph  Model 

The  Evolution  Control  System,  ECS,  uses  the  above  states  to  represent  the 
different  actions  an  evolution  step  goes  through  during  its  lifetime.  The  difference  from 
[52]  is  that  an  assigned  state  is  added  between  the  scheduled  state  and  the  completed  state 
to  differentiate  between  the  cases  in  which  a  step  is  scheduled  (planned)  but  not  yet 
assigned  to  a  designer  and  those  cases  where  the  step  is  assigned  to  a  designer  and  the  work 
is  in  progress.  It  is  always  desirable  to  have  a  complete  schedule  for  planning  purposes  to 
determine  the  feasibility  of  accomplishing  the  required  changes  by  certain  deadline  and 
meeting  various  management  constraints.  This  differentiation  is  needed  for  our  automated 
management  system  (ECS)  in  case  of  suspending  or  abandoning  a  step.  If  the  step  status  is 
scheduled,  then  the  response  is  removing  it  from  the  schedule,  changing  its  status  to 
approved  or  abandoned  respectively,  and  updating  the  schedule.  If  the  step  status  is 
“assigned”,  then  before  issuing  the  previously  mentioned  actions,  a  warning  to  the  manager 
that  an  effort  is  about  to  be  wasted  is  issued,  and  in  case  of  his  confirmation,  “all  completed 
work  if  any”  has  to  be  saved  as  an  attribute  of  the  step  for  future  reference. 

3.  Constraints  on  State  Transitions 

The  following  constraints  are  imposed  on  some  state  transitions  of  composite 
steps  and  their  sub-steps  in  order  to  ensure  consistency  in  the  evolution  histories  containing 
both  composite  and  atomic  steps.  These  constraints  are  the  same  as  those  stated  in  [52]  with 
a  slight  modification  to  correspond  to  the  newly  added  state: 

1.  When  a  step  changes  from  the  “approved”  state  to  the  “scheduled”  state  all  of  its  sub¬ 
steps  automatically  make  this  transition. 

2.  When  a  step  is  rolled-back  from  the  “scheduled”  or  “assigned”  state  to  the 
“approved”  state  all  of  its  sub-steps  automatically  make  the  same  transition. 

3.  A  composite  step  automatically  changes  from  the  “assigned”  state  to  the  “com¬ 
pleted”  state  when  all  of  its  sub-steps  have  done  so. 
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4.  A  composite  step  automatically  changes  to  the  “abandoned”  state  when  all  of  its  sub¬ 
steps  have  done  so. 

5.  When  a  step  changes  to  the  “abandoned”  sute  all  of  its  sub-steps  automatically  make 
the  same  transition. 

6.  When  a  new  sub-step  is  created,  it  enters  the  same  state  as  its  parent  step  and  inherits 
all  version  bindings  associated  with  the  parent  step. 

4.  Specifying  Inputs  to  the  Evolution  Steps 

Evolution  steps  have  two  kinds  of  inputs;  primary  inputs  and  secondary  (non- 
primary)  inputs.  An  input  to  a  step  is  primary  if  and  only  if  it  is  the  previous  version  of  the 
same  object  as  the  output  of  the  step  as  defined  in  equation  (9).  An  initial  approximation  of 
the  secondary  inputs  of  an  evolution  step  can  be  derived  from  the  “used.by”  relation,  since 
a  step  can  depend  on  all  the  components  used  by  its  primary  input  This  is  formalized  as 
follows: 

ALL  (cl  c2:  C,  s:  S:;  c2  used.by  cl&  cl  6  primaryjnput  (s)  => 

c2  6  initial_secondaryJnput  (s))  (14) 

The  set  of  secondary  inputs  to  a  step  should  include  all  the  component  versions 
used  by  the  output  of  the  step.  The  above  is  a  mechanically  derived  initial  approximation 
of  the  set  of  secondary  inputs.  This  approximation  may  need  some  manual  adjustment 
since  design  changes  may  introduce  dependencies  that  did  not  exist  in  the  previous  version, 
and  can  remove  some  dependencies  that  did  exist  Such  adjustments  are  made  via  the 
editing  commands  provided  by  the  ECS. 

5.  Induced  Evolution  Steps 

When  a  step  modifies  a  component  it  implicitly  induces  a  set  of  other  steps  to 
carry  out  the  conesponding  changes  in  all  of  the  other  components  which  depend  on  the 
one  that  is  modified  by  the  original  step  (the  inducing  step).  This  means  that  induced  steps 
produce  versions  of  their  primary  inputs  which  are  consistent  with  the  output  version  of  the 
inducing  step  and  in  the  scope  of  the  current  top  level  evolution  step.  This  concept  is 
formalized  in  equations  (8,  9, 10),  which  provides  the  basis  for  automatic  construction  of 
the  set  of  induced  steps  for  a  given  inducing  step. 
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The  purpose  of  this  construction  is  to  alert  the  software  engineers  and  the 
management  of  the  impact  of  the  proposed  changes  and  to  prevent  consistency  problems 
due  to  incomplete  propagation  of  the  consequences  of  a  change. 

Since  the  inputs  to  the  top-level  evolution  step  are  bound  to  specific  versions  at 
the  time  the  step  is  assigned,  the  set  of  induced  steps  cannot  be  influenced  by  any  changes 
due  to  parts  of  any  other  top-level  steps  that  may  be  executed  concuirendy.  The  predicate 
“current”  is  evaluated  with  respect  to  the  version  bindings  of  the  top  level  step.  For  all  but 
the  initial  version  of  the  components,  the  “used_by”  relationships  can  be  derived  from  the 
secondary  input  relationship  in  the  evolution  history  graph. 


ifc  secondary  input 

FIGURE  7.  Induced  evolution  steps. 

An  example  of  induced  steps  in  a  small  system  implemented  in  Ada  is  shown  in 
Figure  7  (taken  from  [52]  p.  926).  The  initial  configuration  of  the  system  shown  in  the 
figure  consists  of  three  components.  The  step  si  changes  the  main  program  without 
affecting  the  package  specification  and  does  not  trigger  any  induced  steps.  Sinularly  the 
step  s2  changes  the  package  body  without  affecting  the  package  specification  or  triggering 
any  induced  steps.  The  step  s3  changes  the  package  specification  and  triggers  induced  steps 
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s3. 1  and  s3.2,  which  must  update  the  main  program  and  the  package  body  to  be  consistent 
with  the  new  package  specification. 

6.  Induced  State  Transitions 

The  following  constraints  are  imposed  on  some  sute  transitions  of  induced  steps 
and  their  inducing  step  in  order  to  ensure  the  consistency  of  the  configuration.  These 
constraints  are  similar  to  those  stated  in  [52]  with  minor  changes  to  reflect  the  addition  of 
the  “assigned"  state  to  the  model. 

a.  An  inducing  step  can  change  from  the  “assigned”  state  to  the  “completed”  state  only 
when  all  of  its  induced  steps  have  done  so. 

b.  An  induced  step  changes  automatically  from  the  “approved”  state  to  the  “scheduled” 
state  when  its  inducing  step  does  so. 

c.  When  an  inducing  step  is  rolled-back  from  the  “scheduled”  or  “assigned”  state  to  the 
“approved”  state  all  of  its  induced  steps  automatically  make  the  same  transition. 

d.  A  “roll  back”  of  an  induced  step  can  be  done  only  by  rolling  back  all  of  its  inducing 
steps. 

e.  Abandoning  an  inducing  step  causes  all  of  its  induced  steps  to  be  abandoned. 

f.  An  induced  step  can  be  abandoned  only  by  abandoning  its  inducing  step. 

7.  Applying  The  General  Graph  Model  to  PSDL 

The  PSDL  (Prototyping  System  Description  Language)  prototyping  method  uses 
a  hierarchical  decomposition  strategy  for  filling  in  more  details  at  any  level  of  a  prototype 
design.  It  uses  stepwise,  topdown  refinement  to  selectively  refine  and  decompose  critical 
components.  Each  higher  level  component  is  described  in  terms  of  lower  level  components 
and  the  relations  among  them.  The  decomposition  of  each  level  is  a  realization  of  the 
components  at  a  lower  level  of  detail  [S3].  This  hierarchical  structure  of  the  PSDL 
prototyping  method  is  compatible  with  the  underlying  data  model  defined  for  the  evolution 
history  graph  and  introduced  in  section  III.B  above. 

PSDL  has  been  designed  to  prevent  implicit  interactions  between  modules,  thus 
supporting  module  independence.  The  state  of  a  state-machine  operator  is  purely  local  in 
PSDL.  One  cannot  send  a  data  stream  directly  to  a  composite  operator’s  component 
because  the  component  names  are  not  visible  outside  the  implementation  part  of  the 
composite  operator. 


This  locality  makes  it  easier  to  modify  PSDL  prototypes  because  the  number  of 
modules  affected  by  a  change  are  limited  and  can  be  determined  by  a  straightforward 
mechanical  analysis  [S4].  This  is  because  when  a  composite  module  is  decomposed  into 
sub-modules,  the  implementation  of  the  composite  module  uses  its  own  specification  and 
the  specifications  of  the  sub-modules,  but  not  the  implementation  of  the  sub-modules  [52]. 
This  limits  the  impact  of  evolution  steps  and  indicates  that  each  “part.of  ’  relation  between 
a  module  and  its  sub-modules  implies  a  “used.by”  relation  between  the  specification  of  the 
sub-modules  and  the  implementation  of  the  module.  This  also  implies  that  the  “used.by" 
relation  can  serve  as  the  basis  for  automatic  identification  of  inputs  of  a  proposed  evolution 
step  and  identification  of  induced  steps  triggered  by  a  proposed  step. 

The  “used.by”  relation  is  not  only  defined  between  PSDL  components  but  also 
between  the  requirement  hierarchy  and  the  corresponding  PSDL  components  that  fullfil 
each  requiremenL  This  means  each  PSDL  component  can  be  traced  to  a  requirement  in  the 
requirement  hierarchy  and  vice  versa.  This  implies  that  a  change  in  a  system  requirement 
can  automatically  generate  a  proposed  evolution  step  to  modify  the  specification  of  the 
corresponding  component  which,  if  approved  by  management,  can  generate  the 
corresponding  induced  steps  of  this  change  to  the  specification/implementation  modules 
that  use  the  original  specification. 

A  change  request  is  normally  represented  by  an  evolution  step  that  can  be  applied 
to  one  primary  input  component  However,  as  a  natural  result  of  the  explicit  relations 
among  the  modules  in  PSDL,  it  becomes  obvious  that  the  implementation  of  the  change  in 
one  component  can  lead  to  changes  in  several  system  components.  This  leads  to  changing 
the  atomic  step  into  a  composite  step  and  producing  a  new  atomic  step  for  each  of  the 
affected  components.  These  new  atomic  steps  are  called  induced  steps  while  the  step 
inducing  them  is  called  the  inducing  step.  As  a  result,  the  inducing  step  becomes  a 
composite  step  and  the  induced  steps  become  its  substeps. 

In  order  to  eliminate  the  possibility  of  unnecessary  relations  between  composite 
steps  and  their  substeps,  the  composite  evolution  step  may  not  produce  any  new  component 
by  itself,  i.e.,  it  is  an  empty  step. 
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Figure  8  shows  what  we  mean  by  unnecessary  relations  between  a  composite  step 
and  its  substeps.  In  Figure  8.a  step  S 1  is  the  composite  step  with  the  primary  input  A,  steps 
S2  and  S3  are  two  induced  steps  with  primary  inputs  B  and  C  respectively  that  uses  module 
A.  For  step  B  or  C  to  start  step  A  has  to  be  completed  which  is  impossible  because  S 1  is 
composite  step  and  it  will  not  be  completed  unless  S2  and  S3  are  completed  (circular 
dependency).  In  Figure  8.b,  SI  is  designated  as  an  empty  step  with  S2,  S3,  and  S4  as  its 
substeps  that  have  the  same  relations  as  those  between  SI,  S2  and  S3  in  Figure  8. a.  This 
way  S2  can  be  committed  permitting  S3  and  S4  to  start,  when  S3  and  S4  are  completed,  S 1 
is  committed  producing  a  new  configuration  of  the  whole  software  system  incorporating 
this  change. 


FIGURE  8.  Relation  between  composite  step  and  its  substeps 

The  comfiosite  step  decomposition  occurs  when  the  step  is  approved  by  the 
manager.  This  triggers  the  automated  step  analysis  process  that  analyzes  the  relations 
between  the  primary  input  of  each  step  and  the  rest  of  the  system  components,  determines 
the  initial  approximation  of  the  affected  modules  (the  set  of  modules  that  use  the  output  of 
the  step,  which  can  be  approximated  by  those  modules  that  use  the  primary  input  of  the 
step)  that  have  to  be  modified  to  propagate  the  required  changes,  and  creates  a  sub- step  for 
each  of  the  affected  modules.  These  induced  steps  behave  no  differently  than  any  other  step 
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and  they  may  have  relations  with  one  another  or  some  other  evolution  steps.  Since  the 
composite  step  itself  is  an  empty  step,  there  are  no  dependency  relations  between  the 
composite  step  and  its  sub-steps. 

C.  SCHEDULING  MODEL 

The  task  in  our  case  is  to  schedule  a  setofN  evolution  steps  S  ~  {Si,  S2 . relative 

to  a  set  of  M  designers  D  «  (Di,  02,-...  D|^).  The  designers  are  of  three  possible  expertise 
levels  (Low,  Medium,  High}.  Each  step  has  associated  with  it  a  processing  time  tp  (Sj).  a 
deadline  d  (Si),  a  priority  p  (Sj),  and  required  expertise  level  e  (Sj).  Steps  have  precedence 
constraints  given  in  the  form  of  a  directed  acyclic  graph  G  3  (S.  E)  such  that  (Sj.  Sj)  e  E 
implies  that  Sj  cannot  start  until  Si  has  completed. 

Because  of  the  dynamics  of  the  prototyping/evolution  process,  the  steps  to  be 
scheduled  are  only  partially  known.  Time  required,  the  set  of  sub-tasks  for  each  step,  and 
the  input/output  constraints  between  steps  are  all  uncertain,  and  are  ail  subject  to  change  as 
evolution  steps  are  carried  out. 

Our  goal  is  to  dynamically  determine  whether  a  schedule  (the  time  periods)  for 
executing  a  set  of  evolution  steps  exists  such  that  the  timing,  precedence,  and  resource 
constraints  are  satisfied,  and  to  calculate  this  schedule  if  it  exists. 

1.  Scheduling  Constraints 

During  software  system  evolution/prototyping,  constraints  that  reflect  the 
importance  and  partial  ordering  of  implementing  evolution  steps  arise  from  real  life 
situations.  These  constraints  influence  the  evolution  process  and  they  must  be  represented 
in  the  scheduling  model  in  order  to  reach  a  realistic  schedule.  The  set  of  constraints  that 
affect  scheduling  evolution  steps  in  the  context  of  our  model  are  the  following: 

1.  Precedence  constraints. 

2.  Timing  constraints. 

3.  Priority  constraints. 

4.  Resource  constraints. 


The  precedence  constraint  is  used  to  reflect  the  inter-dependencies  between  the  inputs 
and  the  outputs  of  evolution  steps.  The  intent  of  this  constraint  is  to  impose  a  sequential 
ordering  between  given  pairs  of  steps.  The  precedence  constraints  among  evolution  steps 
are  represented  in  the  form  of  a  directed  acyclic  graph  G  =  (S.  E)  such  that  (Sj,  Sj)  6  E 
implies  that  Sj  cannot  start  until  Sj  has  completed. 

The  dependency  relation  between  evolution  steps  implies  a  precedence  constraint 
between  these  steps.  These  relations  can  be  formalized  using  the  dependency  graph 
definition  above  and  considering  C  as  the  set  of  system  components  as  follows: 

ALL(c  ;  C.  Sj.sj;  S  llsj,  c]  e  O  &  [c,  Sj)  e  I ::  (Sj,  sp  6  E)  (14) 

These  dependency  relations  mean  that  an  atomic  evolution  step  cannot  start 
unless  the  module  that  needs  to  be  changed  is  available  as  well  as  all  the  modules  that  affect 
this  module.  Most  of  the  precedence  relations  arc  calculated  automatically.  Additional 
ordering  conscaints  can  be  added  manually  by  the  manager,  due  to  considerations  such  as 
a  designer  with  a  special  skill  is  due  to  be  assigned  to  a  different  project  or  that  one  step 
will  be  easier  or  less  uncertain  if  some  other  step  is  carried  out  flrst. 

The  precedence  attribute  of  a  step,  defined  as  the  set  of  steps  that  precede  this  step, 
is  used  to  resolve  conflicts  when  two  steps  S|  and  $2  are  bound  to  the  same  generic  primary 
input.  It  is  also  used  to  determine  which  version  of  a  secondary  input  component  to  a  step 
S]  is  used  when  this  component  is  specified  by  generic  reference  and  its  current  version  is 
'-nary  input  to  another  step  S2.  If  S2  precedes  Sj  then  the  secondary  input  of  S|  will  be 
boui.w  (o  the  output  of  S2  and  (S2.  S  i )  €  E.  otherwise  it  is  bound  to  the  current  version  (the 
primary  input  of  S2)- 

The  timing  constraints  of  a  step  are  specified  in  terms  of  two  parameters:  the 
deadlines,  the  time  by  which  the  step  must  be  completed  according  to  customer  restrictions 
or  manager’s  resource  planning,  and  the  estimated  duration,  a  management  estimate  of  the 
time  needed  to  perform  the  step. 
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The  priority,  a  small  positive  integer,  is  assigned  to  a  step  to  reflect  the  criticality 
of  its  deadline.  The  deadline  of  a  higher  priority  step  can  be  relaxed  only  if  it  cannot  be  met 
when  the  deadlines  of  all  lower  priority  steps  arc  removed. 

The  priorities  of  different  steps  should  be  compatible  with  the  precedence 
constraints  between  these  steps,  i.e.  no  lower  priority  step  can  precede  a  higher  priority 
step: 

If  (S2.  S 1 )  e  E  implies  that  p  (S2)  >=  p  (S  i )  (15) 

If  (S2,  Sj)  €  E  &  p  (Sj)  >=  p  (S3)  implies  that  p  (S2)  >=  p  (S3)  (16) 

The  ECS  system  should  enforce  these  constraints  and  warn  the  manager  to  make 
the  necessary  changes  (change  either  the  precedence  or  the  priority  of  the  step)  to  comply 
with  these  constraints. 

The  only  resource  constraint  of  a  step  in  our  system  is  specified  in  terms  of  either 
of  two  parameters:  the  expertise  level  required  to  perform  the  step  as  one  of  three  levels 
(low,  medium,  high)  defined  for  the  members  of  the  design  team,  or  by  specifying  a  certain 
team  member  to  perform  the  step. 

In  addition  to  automatically  generated  precedence  constraints,  the  precedence, 
timing,  priority,  and  resource  constraints  are  assigned  manually  by  the  manager  and  may 
be  changed  during  the  evolution  process  according  to  the  state  of  the  system’s  evolution 
and  external  constraints  as  well  as  to  resolve  schedule  conflicts. 

2.  Dynamics  -  What  Can  Change 

Since  one  of  the  main  goals  of  this  system  is  to  support  incremental  replanning  as 
additional  information  becomes  available,  it  is  important  to  define  what  kind  of  additional 
information  can  be  added/updated,  the  impact  of  such  changes  on  both  the  scheduling  and 
assignment  processes,  and  how  this  may  also  impact  the  goal  nf  minimizing  wasted  design 
efforts  due  to  these  changes.  The  candidates  for  change  during  the  evolution/prototyping 
process  are  the  following; 

1.  The  primary  inputs. 

2.  The  secondary  inputs. 

2.  The  affected  modules. 
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3.  The  precedence,  priority,  and  deadline. 

4.  Task  decomposition 

5.  The  estimated_duration  for  performing  each  step. 

6.  The  design  team  members. 

In  the  following  subsections  each  of  these  change  candidates  is  discussed. 

€u  Primary  Input  Changes 

Normally,  an  evolution  step  has  one  primary  input  except  in  case  of  merging 
different  versions  of  the  same  component.  In  this  case  an  adjustment  (addition  or  deletion) 
of  a  primary  input  may  be  needed.  This  change  has  no  additional  effect  on  the  schedule 
because  it  does  not  affect  any  of  the  other  components,  since  all  the  step  attributes  (mainly 
secondaryjnputs  and  affected.modules)  should  have  been  calculated  using  the  original 
primary  input 

b.  Secondary  Input  Changes 

Due  to  the  ongoing  concurrent  changes  and  adding/deleting  of  components 
to/from  the  system,  dependencies  that  did  not  exist  in  the  previous  version  may  be 
introduced,  and  dependencies  that  did  exist  may  be  removed.  These  dependencies  are 
reflected  in  each  step  by  a  set  of  secondary  inputs  (all  the  components  that  are  used  by  its 
primary  input)  which  has  to  be  changed  to  reflect  any  dependency  changes  by  adding  new 
secondary  inputs  to,  or  deleting  existing  secondary  inputs  from  the  secondary_input_set  of 
the  step.  The  additional  impact  of  this  change  depends  on  the  status  of  the  step. 

1.  If  the  step  status  is  “proposed/approved”  then  the  change  has  no  additional  effect. 

2.  If  the  step  status  is  “scheduled”  then  the  impact  in  this  case  includes  the  following: 

a.  modifying  the  dependency  graph  to  reflect  these  changes. 

b.  recalculating  the  schedule  according  to  the  modified  gr^h. 

3.  If  the  step  status  is  “assigned”  then  the  impact  in  this  case  includes  all  the  changes 
mentioned  in  2  above  as  well  as  the  following: 

a.  suspending  any  assigned  steps  that  become  dependent  on  any  uncommitted 
steps. 

b.  assigning  any  new  steps  that  become  ready. 

c.  sending  immutable  copies  of  the  new  secondary  inputs  to  the  corresponding 
designer. 
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Note  that  before  the  ECS  suspends  a  step  it  warns  the  manager  that  the  current 
change  leads  to  the  suspension  of  the  step.  This  gives  the  manager  a  choice  of  either 
confirming  the  change  or  binding  the  modified  secondary  input  to  an  older  version  so  that 
no  suspension  occurs. 

c.  Affected  Modules  Changes 

This  is  used  to  add/delete  affected  modules  to  a  step  after  reviewing  the 
automated  analysis  due  to  missing  relations  in  the  configuration  graph  that  the  system  does 
not  consider  during  this  analysis.  The  impact  of  this  change  depends  on  the  status  of  the 
edited  step. 

1.  If  the  step  status  is  “approved”  then  the  impact  is  adding/abandoning  the  correspond¬ 
ing  step. 

2.  If  the  step  status  is  “scheduled”  then  the  impact  in  this  case  includes  the  effects  men¬ 
tioned  in  1  above  with  the  addition  of: 

a.  modifying  the  dependency  graph  to  reflect  these  changes 

b.  recalculating  the  schedule  according  to  the  modified  graph. 

3.  If  the  step  status  is  “assigned”,  then  the  impact  in  this  case  includes  all  the  effects 
mentioned  in  2  above  as  well  as  the  following: 

a.  suspending  any  assigned  steps  that  become  dependent  on  any  newly  added 
steps 

b.  assigning  any  steps  that  become  ready. 

d.  Precedence,  Priority,  and  Deadline  Changes 

Precedence,  priority,  and  deadlines  are  used  by  both  the  scheduling  and 
assignment  mechanisms  to  resolve  conflicts  regarding  the  dependency  between  different 
steps  and  establish  a  partial  or  total  ordering  among  the  approved  steps.  The  impact  of 
changes  to  any  of  these  parameters  depends  on  the  status  of  the  step. 

1.  If  the  step  status  is  “proposed/approved”  then  the  change  has  no  additional  effect. 

2.  If  the  step  status  is  “scheduled”  tlien  the  impact  in  this  case  includes  the  following: 

a.  modifying  the  dependency  graph  to  reflect  these  changes. 

b.  recalculating  the  schedule  according  to  the  modified  graph 

3.  If  the  step  status  is  “assigned”  then  the  impact  in  this  case  includes  all  the  changes 
mentioned  in  2  above  as  well  as  the  following: 

a.  suspending  any  assigned  steps  that  become  dependent  on  any  uncommitted 
steps 


b.  assigning  any  stq>s  that  become  ready. 

Note  that  when  changing  the  precedence  or  the  priority  of  a  step  the 
compatibility  between  these  two  constraints  should  be  checked  according  to  rules  (16).  and 
(17). 


e.  Step  Decomposition 

The  term  step  decomposition  is  used  to  explain  the  situations  in  which  a 
designer  is  assigned  an  atomic  step,  but  while  carrying  out  his  step  decides  to  decompose 
the  assigned  component  or  change  the  existing  component’s  composition.  It  is  for  these 
cases  that  the  restriction  on  atomic  steps  to  produce  at  most  one  component  has  been 
relaxed  to  permit  atomic  steps  to  produce  zero  or  more  output  components. 

After  this  modification  to  the  graph  model  a  designer  can  decompose  his 
assigned  component  and  work  on  its  subcomponents  within  the  estimated  duration  of  his 
original  component,  or  he  has  to  change  its  estimated  duration  to  avoid  the  warning  of 
missing  the  estimated  finish  dme.  The  ECS  checks  for  such  situations  when  executing  the 
commit.step  command  issued  by  the  designer.  The  following  cases  are  considered  when 
the  designer  commits  his  step: 

1.  The  ECS  looks  first  for  the  modified  venion  of  the  primary.input  component  of  the 
step,  and  commits  it  to  the  shared  data  space  (configuration  graph)  creating  a  new 
version  of  the  primaryjnput  component  of  the  step.  Let  us  designate  this  output 
component  as  the  main  component  and  the  primary.input  component  as  the  original 
component 

2.  If  the  step  output  is  not  atomic  (i.e.,  more  than  one  modified  component  in  the 
designer’s  private.workspace)  then  for  each  of  these  components  the  ECS  does  the 
following: 

a.  If  the  component  is  part.of  the  main  component  the  designer  is  asked  if  he 
wants  to  commit  this  component  and  whether  the  work  in  this  component  is 
complete. 

b.  If  the  component  is  to  be  committed,  the  work  is  complete,  and  the  component  is 
a  part.of  the  original  component  then  it  is  added  to  the  cr.ifiguration  graph  as 
part_of  the  main  component  and  as  the  successor  of  the  version  that  belongs  to 
the  original  component 

c.  If  the  component  is  to  be  committed,  the  work  is  complete,  and  the  component  is 
not  a  part.of  the  original  component  then  it  is  added  to  the  configuration  graph 
as  part.of  the  main  component  and  as  the  first  version  of  itself. 
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d.  If  the  component  is  to  be  committed  and  the  work  is  not  complete,  then  in  addi¬ 
tion  to  adding  the  component  to  the  configuration  graph  as  part_of  the  main 
component  as  mentioned  in  b  and  c  above,  a  step  is  automatically  created  with 
this  component  as  its  primary  input.  This  is  the  case  with  teamwork  where  a 
designer  normally  decomposes  a  component  into  its  subcomponents,  creating 
stubs  for  each  created  subcomponent  then  commits  these  subcomponents,  auto¬ 
matically  creating  a  new  step  for  e^h  of  them. 

e.  For  those  components  that  are  part^of  the  original  component  and  not  part_of 
the  main  component,  the  ECS  asks  if  they  should  be  deleted  and  delete  them 
from  the  main  component  composition  if  confirmed  by  the  designer. 

As  an  example  of  step  decomposition.  Figure  9.a  shows  the  typical  case  when 
a  designer  is  assigned  an  atomic  step  S 1 1  with  component  B  as  its  primary  input  (this  step 
is  part.of  a  top  level  step  SI).  He  did  his  modifications  to  B  and  did  not  touch  its 
decomposition.  The  resulting  system  is  A*  with  a  new  version  B*  of  B.  In  Figure  9.b  the 
designer  changed  the  decomposition  of  B.  He  deleted  F.  added  G.  modified  D,  and  kept  E 
untouched.  When  the  designer  commits  his  work  the  system  checks  for  the  original 
component  B,  commits  it,  creating  the  new  version  B*,  then  commits  D  creating  the  new 
version  D*,  E  is  kept  in  the  new  system  configuration  A*,  F  is  deleted,  and  G  is  added.  If 
the  work  in  G  is  not  completed  (according  to  the  designer’s  response)  a  new  step  si 2  is 
automatically  created  with  component  G  as  its  primary.inpuL  This  new  step  (SI2)  is  a 
sibling  of  step  Sll.  When  S12  commits  its  output  will  replace  component  G  as  part  of 
component  B*.  When  SI  is  committed  the  new  system  configuration  A*  is  automatically 
generated. 


45 


/.  Time  Estimate  Changes 

The  time  estimate  is  a  management  estimation  of  the  time  required  for 
execution  of  each  step.  The  initial  schedule  estimation  is  based  on  these  time  estimates. 
These  estimates  may  differ  from  the  actual  time  needed  by  the  designers  in  charge  of 
executing  the  steps.  Editing  these  estimates  may  be  needed  due  to  actual  time  required  for 
completed  work  or  analysis  of  values  of  similar  work,  or  for  entry  of  time  estimates  for 
automatically  generated  sub-steps.  This  editing  will  provide  a  better  scheduling  estimate. 
The  impact  of  these  changes  also  depends  on  the  status  of  the  step. 

1.  If  the  step  status  is  “proposed  or  approved”  then  the  change  has  no  additional  effect. 

2.  If  the  step  status  is  “scheduled  or  assigned”  then  the  impact  in  this  c?se  includes 
recalculating  the  schedule. 
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g.  Designer-Pool  Changes 

Three  kinds  of  changes  may  take  place  in  the  designer_pooi:  add  designer, 
delete  designer,  and  change  a  designer’s  expertise  level. 

a.  Adding  a  designer  triggers  the  assignment  mechanism  to  find  an  assignment  for  the 
new  designer  if  there  is  one  and  the  rest  of  the  schedule  is  adjusted  accordingly. 

b.  Deleting  a  designer  has  no  impact  if  he  is  not  assigned  to  a  step  and  has  no  planned 
assignment  in  the  schedule,  otherwise  the  manager  is  prompted  for  confirmation, 
then  if  confirmed  the  assigned  step  is  suspended  and  reassigned  to  some  other 
designer  and  the  rest  of  his  planned  assignment  are  rescheduled  to  the  rest  of  the 
design  team. 

c.  Updating  the  designer’s  expertise  level  has  no  immediate  impact  on  the  current 
assignment,  but  the  planned  assignments  are  adjusted  according  to  his  new  expertise 
level. 

h.  Impact  of  Changes 

When  the  impact  of  a  change  includes  suspending  an  assigned  step,  leading 
to  a  rollback  of  some  work  done,  or  rescheduling  some  steps  in  a  way  that  leads  to  missing 
any  of  the  deadlines,  the  system  should  alert  the  manager  to  such  consequences,  giving  him 
the  option  to  continue  with  this  change  or  cancel  it  and  get  back  to  the  original  conditions 
before  the  change.  In  the  first  case  where  a  step  has  to  be  suspended,  the  system  should 
prompt  the  manager  with  the  candidate  steps  for  suspension,  how  long  they  have  been 
assigned,  and  the  estimated  working  time.  In  the  second  case  where  some  deadlines  have 
to  be  missed,  the  system  should  prompt  the  manager  with  the  candidate  steps  for  missing 
their  deadlines  and  the  earliest  completion  time  for  each  step  compared  with  the  completion 
time  before  the  change.  In  both  cases  the  manager  should  have  the  option  to  continue  with 
the  change  or  cancel  it  and  continue  with  the  original  situation. 

3.  Computational  Feasibility 

Scheduling  tasks  with  arbitrary  precedence  constraints  and  unit  computation  time 
in  multiprocessor  systems  is  NP-hard  for  both  the  preemptive  and  nonpreemptivc  cases 
[67]  [84].  Scheduling  nonpreemptive  tasks  with  arbitrary  ready  times  is  NP-hard  in  both 
multiprocessor  and  uniprocessor  systems  [67]  [83]  which  excludes  the  possibility  of  the 
existence  of  polynomial  time  algorithm  for  solving  the  problem.  Hong  and  Leung  [34] 
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proved  that  there  is  no  optimal  on*line  scheduler  can  exist  for  task  systems  that  have  two 
or  more  distinct  deadlines  when  scheduled  on  m  identical  processors  where  m  >  1. 

Scheduling  evolution  steps  to  more  than  one  designer  with  arbitrary  precedence 
constraints  and  arbitrary  deadlines  is  a  combination  of  both  the  multiprocessor  scheduling 
problems  mentioned  above  which  is  shown  by  many  researchers  to  be  NP-hard.  These 
negative  results  dictate  the  need  for  heuristic  approaches  to  solve  scheduling  problems  in 
such  systems. 

D.  RESOURCE  MODEL 

The  only  resource  required  in  our  model  is  the  members  of  the  design  team.  They  are 
represented  as  a  set  D=  (Dj,  D2,-..,  Dm),  where  M  is  the  number  of  designers  in  the  design 
team.  Each  team  member  has  associated  with  him  an  expertise  level  e  (Dj)  to  reflect  his 
expertise.  The  expertise  levels  represented  are  (low,  medium,  high).  The  resource 
constraint  of  a  step  determines  what  level  of  expertise  is  (at  least)  required  of  a  designer 
who  can  be  assigned  to  the  step.  Note:  The  manager  may  even  require  a  specific  designer 
to  perform  a  certain  step. 

E.  ECS  MODEL 

The  purpose  of  the  Evolution  Control  System,  ECS,  is  to  provide  automated  support 
for  changes  in  plan  during  the  execution  of  the  plan,  and  provide  automatic  decision 
support  for  planning  and  team  coordination  based  on  design  dependencies  captured  in  the 
configuration  model.  The  ECS  also  manages  the  software  evolution  steps  from  its  creation 
to  completion  and  provides  automatic  version  control  and  configuration  management  for 
the  products  of  these  steps.  Additionally,  the  system  manages  the  design  team  through 
automation  of  the  evolution  steps’  assignments  to  members  of  the  design  team  in  such  a 
way  that  maximizes  the  team’s  effort,  supports  cooperative  teamwork,  and  meets  the 
management  constraints  such  as  precede  ice,  priorities,  and  deadlines. 

1.  Context  Model 

The  Evolution  Control  System  (ECS)  interacts  with  two  external  entities:  the 
software  evolution  manager  and  the  software  designer.  These  represent  classes  of  human 
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users  rather  than  external  software  or  hardware  systems.  There  is  one  external  interface  for 
each  class  of  user:  the  managerjnterface  and  the  designer.interface.  Both  of  these 
interfaces  are  views  of  the  proposed  ECS.  The  message  flow  diagram  in  [10]  and  the 
stimulus*response  diagrams  in  Figures  10.  11.  12  and  13  show  the  context  of  the  system 
and  the  available  commands,  their  effects  and  the  possible  error  conditions. 


FIGURE  10.  ECS  message  flow  diagram 

2.  Event  List 

The  event  list  for  the  ECS  consists  of  25  events.  Most  of  the  events  are  command- 
driven.  The  following  is  a  list  of  the  events;  events  triggered  by  the  manager  are  marked  M. 
events  triggered  by  a  designer  are  marked  D.  and  common  events  for  both  designers  and 
manager  are  marked  C  following  the  event  name. 


1.  create_prototype  (M) 

3.  approve_step  (M) 

5.  commit_step  (M) 
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2.  cTeate_step  (Q 

4.  schcdule_step  (M) 

6.  commit_substep  (D) 


7.  abandon.step  (M) 

9.  show.steps  (C) 

1 1.  add.designer  (M) 

13.  dcsigner_cxpcrtisc_lcvcl  (M) 
15.  manager.confinnation  (M) 
The  edit_step  event  is  a  set  of  evt 

I.  add_primary_input 

3.  add_affected_moduIes 
5.  delete_secondary_input 
7.  update_precedence 
9.  update.deadline 

II.  step_expcrtisejevel 


8.  suspend_step  (M) 

10.  show.schedule  (C) 

12.  drop.designcr  (M) 

14.  edit_step  (M) 

by  itself  as  listed  below: 

2.  add_secondary_input 
4.  delete_priinary_input 
6.  delete_affected_modules 
8.  update_priority 
10.  update.estimated.duration 


3.  State  Model  And  Related  Concepts 

The  state  of  the  ECS  consists  of  a  configuration  graph,  a  schedule,  a  set  of 
designers,  and  mappings  giving  the  following  attributes  for  each  evolution  step:  deadline, 
estimated  duration,  precedence,  priority,  status  and  required  expertise  level.  The  formal 
definitions  of  the  state  model  and  the  constraints  on  a  feasible  schedule  are  defined  in 
Appendix  A.l. 


a.  Configuration  graph 

As  presented  in  section  B,  the  evolution  history  is  modeled  as  a  graph  Gs[C, 
S,  CE.  SE,  I,  O].  This  graph  is  a  directed  acyclic  graph  (bipartite  with  respect  to  the  edges 
1  and  O).  C  and  S  are  the  two  kinds  of  nodes  (C:  software  component  nodes,  and  S: 
evolution  step  nodes  respectively).  Each  node  has  a  unique  identifier.  C  and  S  nodes 
alternate  in  each  path  that  has  only  I  and  O  edges.  This  represents  the  evolution  history  view 
of  the  graph.  The  edges  repi^icnt  the  “part_of  ’  (between  a  sub-component  of  a  composite 
component  and  the  composite  component)  and  “used.by”  relations  (defined  between 
components  to  represent  the  situation  where  the  semantics  or  implementation  of  one 
component  A  depends  on  another  component  B;  B  used_by  A)  between  the  software 
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components  of  a  given  configuration  (  CE  c  C  x  C).  the  “part_of’  relation  between  a 
substep  of  a  composite  step  and  the  composite  step  (  SEqSxS  ),  the  input  relation 
between  the  system  components  which  must  be  examined  to  produce  output  components 
that  are  consistent  with  the  rest  of  the  system  and  the  conesponding  evolution 

steps(/  C  C  X  5),  and  output  relation  between  evolution  steps  and  the  components  they 
produce  (OqSxC).  System  components  are  immutable  versions  of  software  source 
objects  that  cannot  be  reconstructed  automatically.  This  graph  is  referred  to  from  now  on 
as  the  configuration  graph.  In  Appendix  A.l.a  we  formalize  the  structure  of  this  graph  as 
well  as  the  two  data  types;  components  and  steps  that  constitute  its  nodes 

b.  Designer^Poal 

Designers  are  the  only  resource  used  by  the  ECS.  The  type  designer  is  part  of 
the  ECS  state  model.  Formal  specifications  of  type  designer  is  presented  in  Appendix 
A.l.b. 

c.  Schedule 

The  schedule  in  our  system  is  a  dau  structure  representing  the  mapping 
between  the  steps  and  the  scheduled  designer  to  perform  each  step  together  with  the 
estimated  start  and  Hnish  time.  Formal  specification  of  this  data  structure  and  the  relevant 
concepts  are  presented  in  Appendix  A.l.c. 

4.  Manager  Interface 

The  manager  interface  to  the  ECS  enables  the  manager  to  create  new  prototypes, 
provide  for  the  evolution  of  the  existing  prototypes  via  a  complete  set  of  commands  for 
creating,  editing,  scheduling,  suspending/abandoning  and/or  committing  evolution  steps, 
and  manage  the  dcsigner_pool  data  via  add_designcr,  drop_designcr,  and 
designer_expertise_level  commands.  The  formal  specifications  of  the  various  commands 
with  the  different  responses  for  each  command  are  defined  in  Appendix  A.2  and  Appendix 
A.3. 
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5.  Designer  Interface 

The  designer  interface  to  the  ECS  enables  the  designer  to  view  the  steps  in  a  given 
prototype  with  a  given  status  and  get  the  sub-steps  assigned  to  him.  This  interface  also 
enables  the  designer  to  create  a  sub-step  of  an  assigned  step  as  well  as  committing  the 
assigned  sub-step.  The  formal  specifications  of  the  various  commands  with  the  different 
responses  for  each  command  arc  defined  in  Appendix  A.2  and  Appendix  A.4. 
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FIGURE  11.  Stimulus  Response  diagram  for  the  edit  interface 
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Done 


FIGURE  12.  Stimulus  Response  diagram  for  the  manager  interface 
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FIGURE  13.  Stimulus  Response  diagram  for  the  designer_pooi  view 


done 


FIGURE  14.  Stimulus-Response  diagram  fur  the  designer  interface 
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F.  VALroATION  OF  ECS  SPECIFICATION 


I.  A  Typical  Scenario 

Assume  that  we  have  a  system  Sys  consisting  of  three  main  modules  Ma,  Mb  and 
Me  as  illustrated  in  Figure  15.  Ma  consists  of  two  objects  Oa,  Ob  and  Mb  is  atomic  while 
Me  consists  of  Oc,  Od,  and  Oe.  The  relation  “part^of*  represents  this  hierarchical  structure 
as  follows;  Ma  part_of  Sys,  Mb  part_of  Sys,  Me  part_of  Sys,  Oa  part_of  Ma,  Ob  part_of 
Ma,  Oc  part_of  Me,  Od  part_of  Me.  Oc  part_of  Me.  The  “part_of  *  relation  also  implies  a 
“used_by”  relationship  between  the  implementation  module  of  the  parent  component  and 
the  specification  modules  of  the  children  con.ponents.  The  uscd_by  relation  for  the 
example  is:  every  specificadon  module  of  a  component  is  used_by  its  implementation 
module  such  as  Sys.spcc  uscd_by  Sys.imp,  Ma.spec  uscd_by  Ma.imp,  etc.,  and  Oc.spcc 
uscd_by  Oe.imp.  The  used_by  reladon  between  Oc  and  Oc  can  only  arise  in  PSDL  if  a 
timer  is  defined  in  Sys  or  Me,  this  timer  is  started,  stopped,  or  reset  in  Oc  and  the  value  of 
this  timer  is  read  by  Oe.  This  kind  of  dependency  should  occur  rarely  in  practice.  In  figure 
3  a  thin  arrow  from  A  to  B  means  A  used_by  B,  while  a  thick  arrow  from  A  to  B  means  A 
pan.of  B  &  A  used.by  B. 

Assume  our  design  team  has  three  members:  Designer  dl  with  cxpertise_Ievel 
high.  d2  with  expertise_lcvel  medium  and  d3  with  cxpcrtisejcvcl  low.  One  typical 
scenario  of  a  change  to  this  system  can  be  described  as  follows: 

1.  Three  evolution  steps  are  created  (using  the  crcate_step  command)  by  the 
designers,  based  on  user  feedback  from  a  prototype  demonstration,  as  shown  in  Table  1. 
The  system  will  assign  a  unique  number  to  each  of  the  created  steps.  The  status  of  each 
newly  created  step  is  “proposed”.  Each  created  step  is  added  to  the  configuration  graph  as 
an  isolated  node  (at  this  point,  the  primary  inputs  of  the  steps  are  specified  by  generic 
references,  since  we  have  not  yet  determined  which  version  of  the  primary  inputs  will  be 
acted  on  by  each  step)  with  no  input  or  output  edges. 

Create.step  command  also  triggers  the  automated  step  analysis  process  that 
analyzes  the  relations  between  the  primary  input  of  each  step  and  the  rest  of  the  system 
components,  determines  the  initial  approximation  of  the  affected  modules  (the  set  of 
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modules  that  use  the  output  of  the  step,  which  can  be  approximated  by  those  modules  that 
use  the  primary  input  of  the  step)  that  have  to  be  modified  to  propagate  the  required 
changes.  The  analysis  process  is  done  as  follows: 

a.  The  system  examines  the  image  of  the  primary  input  modules  under  the 
“used_by”  relationship  to  find  out  what  other  modules  have  to  be  modified  to  reflect  and 
propagate  the  required  changes.  By  examining  the  primary  input  to  step  si  the  system 
should  find  out  that  the  only  modules  that  use  Ma.spcc  are  {Ma.imp,  Sys.imp).  The  same 
analysis  is  done  for  both  steps  two  and  three,  resulting  in  the  two  induced  sets  {Sys.imp) 
and  { 1  respectively. 

The  ECS  also  calculates  the  secondary  inputs  of  the  step  as  the  modules  used_by 
the  primary  Jnput  of  the  step. 


Sys.1.1 


FIGURE  15.  Version  1  of  the  given  system. 

2.  The  manager  reviews  the  proposed  steps  and  its  calculated  secondary  inputs 
and  affected  modules  where  he  can  edit  these  automatically  calculated  attributes  using  the 


“edit.step”  command.  The  manager  also,  adds  management  constraints  such  as  priority 
(type  natural),  precedence  (set  of  preceding  steps),  estimated  time  for  completing  the  step 
(hours),  and  deadline  (time).  Assume  for  the  sake  of  this  example  that  the  manager  added 
the  values  shown  in  Table  1  for  these  attributes.  The  manager  also  can  modify  any  of  the 
inputs  to  the  step  (using  the  edit.step  interface).  When  the  manager  approves  the  step 
(using  the  approve.step  command)  its  status  is  changed  from  proposed  to  “approved”. 


■ 

primar]r_ 

input 

secondary 

_input 

step_ 

expertise 

_level 

precedence 

priority 

deadline 

status 

si 

Ma.spec.1 

“ 

Medium 

10 

d4  16 

proposed 

s2 

Sys.spec.1 

- 

High 

si 

9 

d-f  18 

proposed 

s3 

Oe.imp.l 

Oc.spec.l 

Oe.spec.l 

Low 

7 

d-t-20 

proposed 

TABLE  1.  THE  PROPOSED  STEPS  AND  THEIR  ATTRIBUTES. 


3.  Approving  the  step  makes  the  system  automatically  create  an  atomic  sub-step 
of  the  top  level  parent  step  for  each  affected  module.  Table  2  shows  the  different  substeps 
created  for  each  step.  These  sub-steps  inherit  the  version  bindings  of  their  respective  super¬ 
step  as  well  as  its  precedence,  priority,  and  deadline.  These  sub.steps  are  added  to  the 
configuration  graph  with  part.of  edges  linking  them  to  their  super-steps. 

4.  The  manager  enters  the  estimated  duration  for  each  of  the  substeps.  In  this 
scenario,  the  estimated  durations  entered  are  the  values  shown  in  Table  2.  The  manager  can 
then  schedule  the  steps  (using  the  schedule.step  command),  which  triggers  the  scheduling 
and  job  assignment  mechanisms.  The  schedule  (including  the  planned  assignment  of  a 
designer  for  each  step  and  the  estimated  stan  and  finish  time  for  each  step)  is  built 
incrementally  with  the  issuing  of  the  scheduie_step  command  for  each  step  as  follows; 

a.  When  step  si  is  scheduled  (using  the  schedulc_step  command),  the 
manager  gets  a  schedule  which  includes  the  substeps  of  step  si  as  shown  in  Table  3.  This 
schedule  meets  its  deadline.  The  time  T  is  the  time  when  the  schedule  is  produced.  As 
indicated  in  Table  3,  s  1.1  is  automatically  assigned  to  d2,  the  status  of  s  1.1  is  changed  to 
“assigned”,  the  primary  input  of  sl.l  is  bound  to  Ma.spec.1.1.  a  mutable  copy  of 
Ma.spec.  1 . 1  is  sent  to  the  private  workspace  of  designer  d2,  and  a  message  (e.g.,  an  e_mail) 
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is  sent  to  d2  telling  him  about  his  assignment.  Notice  that  s  1 .2  and  s  1 .3  are  not  assigned  yet 
because  they  are  dependent  on  sl.l.  The  assignment  of  sl.2  and  sl.3  will  be  triggered  by 
the  commitment  of  sl.l  that  makes  both  of  them  ready  to  be  assigned. 


■ 

substeps 

primary^ 

input 

secondary 

_iaput 

step_exp 

ertise_le 

vel 

estimated 

_duration 

status 

si 

sl.l 

Ma.spec.1 

Medium 

7 

approved 

sl.2 

Sys.iinp.l 

Sys.spec.1 
Ma.spec.1 
Mb.spec.l 
Me  .spec.  1 

Medium 

6 

approved 

sl.3 

Ma.imp.1 

Ma.spec.1 

Oa.spec.1 

Ob.spec.l 

Medium 

3 

approved 

s2 

s2.1 

Sys.spec.l 

high 

6 

approved 

s2Jl 

Sys.iinp.l 

Sys.spec.l 

Ma.spec.1 

Mb.q)ec.l 

Mc.spec.1 

high 

5 

approved 

s3 

s3.1 

Oe.in)p.l 

Oe.spec.1 

Oc.spec.1 

low 

5 

approved 

TABLE  2.  THE  SUBSTEPS  CREATED  FOR  EACH  STEP 


step# 

designer 

finish_time 

sl.l 

d2 

T 

T+7 

sl.2 

d2 

T+7 

T+13 

sl.3 

dl 

T+7 

T+10 

TABLE  3.  THE  CURRENT  SCHEDULE  AFTER  SCHEDULING  si 

b.  When  step  s2  is  scheduled  (using  the  schedule_stcp  command)  shortly  after 
scheduling  si  (we  can  neglect  the  time  difference  between  scheduling  si  and  s2  relative  to 
the  time  units  used  for  estimating  efforts  due  to  the  difference  in  magnitude),  an  updated 
schedule  is  calculated  accordingly  as  shown  in  Table  4.  Since  the  new  schedule  is  feasible, 
it  becomes  the  current  schedule  and  it  is  sent  to  the  manager.  Having  s2.1  ready  to  be 
assigned  triggers  the  assignment  mechanism  that  assigns  s2.1  to  dl.  The  status  of  s2.1  is 


automatically  changed  to  “assigned”,  the  primary  input  of  s2. 1  is  bound  to  Sys.spec.  1 . 1 .  a 
mutable  copy  of  Sys.spec.  1 . 1  is  sent  to  the  private  workspace  of  designer  d  1 .  and  a  message 
is  sent  to  dl  telling  him  about  his  assignment. 


step# 

designer 

l2j23E!!3l: 

sl.l 

d2 

T 

T+7 

$1.1 

dl 

T 

T+6 

si. 2 

d2 

T+7 

T+13 

sl.3 

dl 

T+7 

T+10 

s2.2 

dl 

T+13 

T+18 

TABLE  4.  THE  CURRENT  SCHEDULE  AFTER  SCHEDULING  s2 

c.  When  s3  is  scheduled  (using  the  schedule_step  command)  at  t  =*  T+3,  an 
updated  schedule  is  calculated  accordingly  as  shown  in  Table  S.  Since  the  new  schedule  is 
feasible,  it  becomes  the  current  schedule  and  it  is  sent  to  the  manager.  The  updated  schedule 
is  also  feasible.  Having  s3.1  ready  to  be  assigned  triggers  the  assignment  mechanism  that 
assigns  s3.1  to  d3.  The  status  of  s3.I  is  automatically  changed  to  “assigned”,  the  primary 
input  of  s3.1  is  bound  to  C)e.imp.l.l,  a  mutable  copy  of  Oe.imp.1.1  and  immutable  copies 
of  the  secondary  inputs  to  s3. 1  (Oe.spec.  1.1,  Oc.spec.  1 . 1 )  arc  sent  to  the  private  workspace 
of  designer  d3,  and  a  message  is  sent  to  d3  telling  him  about  his  assignment 


step# 

designer 

^33231 

imm] 

sl.l 

d2 

T 

T+7 

s2.1 

dl 

T 

T+6 

s3.1 

(13 

T+3 

T+8 

sl.2 

(12 

T+7 

T+13 

SlJ 

dl 

T+7 

T+10 

s2.2 

dl 

T+13 

T+18 

TABLE  5.  THE  CURRENT  SCHEDULE  AFTER  SCHEDULING  s3 


S.  Since  the  three  designers  are  informed  about  their  assignment  and  the 
components  required  for  each  step  exist  in  the  corresponding  designer’s  private  workspace, 
the  designers  can  start  their  assignments  immediately.  The  rest  of  the  assignments  are 
triggered  by  cither  the  commitment  of  an  assigned  step,  which  makes  the  immediate 
successor  steps  ready  when  there  are  idle  designers  waiting  for  tasks,  or  the  availability  of 
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a  designer  who  has  completed  a  previous  task  when  there  ".rr  other  tasks  ready  to  be 
assigned.  Assuming  a  situation  where  everything  goes  as  scheouJed.  the  following  actions 
take  place: 

a.  When  dl  issues  the  commit_step  command  at  t  s2.1  is  committed 
producing  Sys.spec.1.2  and  adding  the  corresponding  node  and  edge  to  the  configuration 
graph,  the  private  workspace  of  designer  dl  is  cleared  and  he  becomes  idle.  Committing 
s2. 1  and  having  d  1  idle  triggers  the  assignment  mechanism  that  finds  no  ready  step  for  him. 

b.  When  d2  issues  the  commit.step  command  at  t  -T+7,  s  1.1  is  committed 
producing  Ma.spec.1.2  and  adding  the  corresponding  node  and  edge  to  the  conflguration 
graph,  the  private  workspace  of  designer  d2  is  cleared  and  he  becomes  idle.  Committing 
sl.l  makes  si. 2  and  si. 3  ready  to  be  assigned,  it  also  triggers  the  assignment  mechanism 
that  assigns  si. 2  and  si. 3  to  d2  and  dl  respectively,  automatically  copying  both  the  primary 
and  secondary  inputs  of  each  step  to  the  corresponding  designer’s  private  workspace, 
changing  their  status  to  “assigned”,  and  sending  both  of  them  messages  about  their  new 
assignment. 

c.  When  d3  finishes  his  assignment  at  t  sT+S  and  issues  the  commit.step 
command,  s3.1  is  committed  which  means  adding  the  output  of  s3.1  (Oe.imp.1.2)  to  the 
configuration  graph  (shared  data  space)  as  a  component  node,  and  the  corresponding  edge 
(s3.1,  Oe.imp.1.2)  as  an  output  edge.  The  private  work  space  of  d3  is  cleared  and  d3 
becomes  idle.  Committing  s3. 1  as  the  only  substep  of  s3  triggers  the  automatic  commitment 
of  s3  producing  the  new  system  version  Sys.1.2  as  illustrated  in  Figure  16.  Having  designer 
d3  idle  triggers  the  assignment  mechanism  diat  finds  no  ready  step  to  be  assigned  to  d3. 

d.  When  dl  issues  the  commit_stcp  command  at  t  =T+10,  sl.3  is  committed 
producing  Ma.imp.1.2  and  the  corresponding  node  and  edge  are  added  to  the  configuration 
graph,  the  private  workspace  of  designer  dl  is  cleared  and  he  becomes  idle.  Having  dl  idle 
triggers  the  assignment  mechanism  that  finds  no  ready  step  for  any  of  the  idle  designers. 

c.  When  d2  issues  the  commit_substep  command  at  t  =T+13,  si. 2  is 
committed  producing  Sys.imp.1.2  and  the  corresponding  node  and  edge  are  added  to  the 
configuration  graph,  the  private  workspace  of  designer  d2  is  cleared  and  he  becomes  idle. 
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Committing  si. 2  makes  s2.2  ready  to  be  assigned  which  triggers  the  assignment 
mechanism  that  assigns  s2.2  to  dl.  Conunitting  sl.2  as  the  last  substep  of  step  si  triggers 
the  automatic  commitment  of  si  producing  the  new  system  version  Sys.1.3  as  illustrated  in 
Figure  17.  Similar  actions  take  place  when  committing  s2.2  and  that  lead  to  the  automatic 
commitment  of  step  s2  producing  the  new  system  version  Sys.1.4  as  illustrated  in  Figure 
17. 

This  typical  scenario  illustrates  that  the  ECS  provides  the  necessary  commands 
needed  to  create,  .ipprove,  schedule  and  commit  an  evolution  step,  as  well  as  add  its 
management  constraints,  and  trigger  the  assignment  mechanism.  The  managerial  functions 
of  determining  the  affected  modules  of  a  change  and  automatically  creating  evolution  steps 
for  propagating  these  changes  are  automated.  The  manager  retains  the  option  to  override 
any  automatic  calculations  through  the  edit  commands  (add  and  delete  affected.modules) 
and  may  direct  the  continuity  of  actions  by  his  approval  via  the  approve.step  command. 
The  planning  process  is  automated  via  the  scheduling  mechanism  which  is  triggered  by  the 
schedule.step  command.  This  scheduling  mechanism  finds  a  feasible  schedule  if  one  exists 
or  gives  suggestions  to  the  manager  in  order  to  get  a  feasible  one,  while  giving  the  manager 
the  option  to  accept  HCS  suggestions  or  modify  the  management  constraints  to  accurately 
reflect  all  the  management  concerns. 

The  automatic  assignment  of  the  ready  steps  to  the  idle  designers  as  well  as  the 
triggering  actions  of  these  assignments  are  also  illustrated.  The  ECS  simplifies  the 
designer’s  task  by  sending  copies  of  all  the  components  he/she  needs  to  complete  his  task 
(primary  and  secondary  inputs)  in  addition  to  a  message  telling  him  about  the  new 
assignment  that  resides  in  his  private  workspace.  As  soon  as  the  designer  finishes  his  task 
he  can  directly  issue  the  commit.step  command  without  having  to  worry  about  versioning 
his  component  or  controlling  the  configuration  it  belongs  to  since  the  version  and 
configuration  control  functions  are  automated  and  transparent  to  the  designer. 

This  scenario  also  illustrates  the  incremental  planning  nature  of  the  system  where 
new  steps  can  be  added  to  the  schedule  when  they  are  available,  and  automatically 
scheduled  either  by  finding  a  feasible  schedule  if  one  exists  or  providing  suggestions  and 
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2,  Scenario  for  a  Missed  Estimated  Finish  Time 

Now  consider  that  our  example  does  not  go  so  smoothly  and  designer  62  was 
unable  to  finish  his  assignment  si. 2  by  its  estimated  finish  time  t »  T+n.  The  assignment 
mechanism  should  alert  the  designer  that  the  estimated  finish  time  has  passed  and  ask  for 
formulation  of  a  new  estimate.  The  designer  either  responds  by  committing  the  step  or 
entering  a  new  estimated.duration  for  this  step.  The  schedule  is  then  recalculated.  If  the 
new  estimated.duration  is  9  instead  of  the  original  value  6.  tlien  the  schedule  is  recalculated 
as  shown  in  Table  6. 


step# 

designer 

stert_tinie 

finish_tine 

sl.l 

d2 

T 

T+7 

s2.1 

dl 

T 

T+6 

$3.1 

(13 

T+3 

T+8 

$1.2 

d2 

T+7 

T+16 

$1.3 

dl 

T+7 

T+IO 

$2.2 

dl 

T+16 

TABLE  6.  THE  CURRENT  SCHEDULE  AFTER  THE  NEW 
ESTIMATED_DURATION  OFsL2 

In  this  schedule  s2  has  missed  its  deadline.  Note  that  s2.2  depends  on  si. 2.  and 
si .2’s  new  finish  time  is  t  =  T-t-lti  and  s2.2  needs  5  time  units  to  finish,  the  manager  gets  a 
warning  that  s2  will  miss  its  deadline  and  the  suggestion  of  a  new  deadline  to  be  equal  to 
the  estimated  finish  time. 

The  system  in  this  case  monitors  the  estimated  finish  times  and  warns  the 
corresponding  designer  if  the  finish  time  of  his  task  is  reached  without  issue  of  the 
commit.step  command.  The  system  also  warns  the  manager  in  this  case  only  if  the  designer 
chooses  to  change  the  estimated  duration  of  his  task  and  this  change  leads  to  missing  any 
of  the  deadlines  of  the  steps  and  provides  the  manager  with  appropriate  suggestions. 

3.  Scenario  for  an  Early  Commit 

Now  consider  designer  d2  finishes  his  assignment  si. 2  after  4  time  units  instead 
of  6  time  units.  In  this  case  the  system  will  not  wait  until  t  =  T+  16  to  assign  s2.2,  but  s2.2 
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is  assigned  right  away  giving  it  a  chance  for  early  completion,  and  the  schedule  is  adjusted 
as  shown  in  Table  7. 

In  this  case  the  positive  effect  of  finishing  a  task  early  may  lead  to  a  ripple  of 
positive  effects  for  the  whole  schedule  if  the  next  task  for  the  designer  who  finished  early 
is  ready.  If  the  next  assignment  is  not  ready  or  no  next  assignment  exists  for  the  designer, 
the  schedule  will  not  be  affected.  As  an  example,  if  d3  finishes  s3. 1  at  t  s  T  -«•  6,  the  schedule 
will  not  be  affected  because  there  is  no  other  ready  step  that  requires  a  low  expertisc_levcl. 


step# 

designer 

sl.l 

d2 

T 

T+7 

s2.1 

dl 

T 

T+d 

s3.1 

d3 

T+3 

T+8 

si. 2 

d2 

T+7 

T+11 

st.3 

dl 

T+7 

T+10 

S2.2 

dl 

T+ll 

T+16 

TABLE  7.  THE  CURRENT  SCHEDULE  AFTER  THE  EARLY  COMMIT  OF 

sL2 

4.  Scenario  for  Changing  the  Precedence  of  a  Step 

Using  Table  S  as  our  final  schedule,  a  possible  change  that  can  occur  as  the 
schedule  is  carried  out  is  changing  the  precedence  of  one  or  more  steps.  Consider  that  the 
manager  decided  to  change  the  precedence  of  step  si  from  none  to  be  preceded  by  step  s2 
and  the  precedence  of  s2  to  be  preceded  by  none  (using  the  update_precedence  command). 
As  soon  as  a  precedence  changes  the  system  checks  two  conditions  for  conflict:  I)  that  the 
new  precedence  does  not  lead  to  a  circular  dependency  ber^^een  the  scheduled  steps  and  2) 
that  there  is  compatibility  between  the  priority  of  this  step  and  the  priorities  of  the  steps  that 
precede  this  step  and  warn  the  manager  accordingly. 

It  our  case  changing  the  precedence  of  s2  produces  no  warning  messages  when  it 
happens.  Changing  the  precedence  of  si  leads  to  different  warnings  according  to  when  it 
takes  place.  If  the  precedence  of  si  is  changed  before  that  of  s2,  the  manager  gets  the 
warning  “circular^precedence”  (at  this  point  si  precedes  s2  and  s2  precedes  si)  which  will 
be  eliminated  by  changing  the  precedence  of  s2.  When  this  warning  is  fixed  or  the 
precedence  of  si  is  changed  second  the  manager  gets  the  warning  “priority .conflict” 
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because  s2  now  precedes  si  and  p  iority  of  si  is  greater  than  that  of  s2.  This  conflict  is 
solved  by  changing  the  priority  of  si  to  the  value  8  (using  the  update_priority  command). 
This  last  change  is  also  checked  for  conflicts  and  none  are  found. 

The  impact  of  this  change  on  the  cunent  schedule  depends  on  when  such  a 
change  takes  place.  Let  us  consider  two  cases  where  the  impact  is  different  as  an  example 
of  the  capabilities  of  the  ECS.  In  the  first  case  we  consider  the  situation  where  the  change 
takes  place  before  t  =  T+  7  and  the  second  one  is  at  t  =  T+8. 

a.  Changing  Precedence  Leading  to  an  Infeasible  Schedule 

When  the  precede  :e  change  occurs  before  commitment  of  si. I  at  t  =  T+7. 
the  manager  gets  the  warning  “infeasible_schcdulc”  (because  si  misses  its  deadline)  and 
the  suggestion  that  the  deadline  of  si  should  be  changed  to  17  instead  of  16.  Since  this  value 
is  the  lower  bound  (it  is  the  total  execution  time  of  three  dependent  steps),  the  manager  has 
the  option  of  cither  to  accept  the  system’s  suggestion  or  to  undo  the  change  and  keep  the 
original  feasible  schedule.  The  resulting  schedule  when  the  manager  accepts  the  system’s 
suggestion  is  shown  in  Table  8. 


step# 

designer 

start_time 

finish_tioie 

s2.1 

dl 

T 

T+6 

sl.l 

d2 

T 

T+7 

s3.1 

(13 

T+3 

T+8 

s2.2 

dl 

T+6 

T+11 

sl.3 

d2 

T+7 

T+10 

sl.2 

d2 

T+11 

|T+17"'.  1 

TABLE  8.  SCHEDULE  AFTER  CHANGING  THE  PRECEDENCE  OF  SI,  S2 

BEFORE  T+7 

h.  Changing  Precedence  Leading  to  Infeasible  Schedule  and  Step  Suspension 
When  the  precedence  change  occurs  at  t  =  T-r8,  after  committing  sl.l  and 
assigning  si. 2,  step  si. 2  becomes  dependent  on  s2.2  and  s2.2  is  not  yet  assigned.  The  ECS 
sends  a  warning  to  the  manager  that  s  1 .2  has  to  be  suspended.  At  this  point  the  manager  has 
the  option  either  to  reject  the  suspension  of  si. 2  and,  as  a  result,  the  precedence  change  is 
undone  and  the  original  schedule  is  restored,  or  confirm  the  suspension  of  si  .2.  In  the  latter 
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case,  the  ECS  calculates  the  updated  schedule  which  includes  suspending  si  2  until  s2  2  is  assigned 
and  completed.  As  a  result,  si. 2  is  automatically  suspended  by  sending  a  message  to  its  designer 
telling  him  that  the  step  is  suspended,  clearing  his  pnvate  workspace,  and  sending  him  his  new 
assignment  it  there  is  one.  The  manager  then  gets  another  warning  that  the  updated  schedule  is 
inteasible  (si  misses  its  deadline).  Again  the  manager  has  the  option  to  either  accept  the  updated 
inteasiblc  schedule  or  to  tunc  the  other  management  constraints  to  get  a  feasible  one. 


step  4 

designer 

startjime 

hnisb_time 

si  1 

d2 

T 

T*7 

s;.i 

dl 

T 

T+6 

s.t.l 

dt 

T+t 

T+H 

sl.t 

dl 

T*7 

T-t-Ki 

s2.: 

dl 

T*ll) 

T+IS 

si  2 

d2 

T+fS 

fTOl— 1 

TABLE  9.  SCHEDl’LE  AFTER  CH  ANGINC  THE  PRECEDENCE.  CASE  2 

This  scenario  illustrates  how  the  ECS  keeps  the  manager  informed  of  the 
consequence.s  of  his  deci.sjons  and  gives  him  the  necessary  data  to  take  appropriate  action.  It  also 
shows  how  a  step  is  automatically  suspended  after  manager  confirmation  without  costing  him  or 
the  designer  any  additional  effort.  This  facilitates  streamlining  of  both  of  their  tasks. 

5.  .Scenario  for  Changing  the  Decompusitiun  of  an  Assigned  Task 

Let  us  consider  again  the  typical  case  where  everything  goes  smoothly  as  scheduled  in 
Table  5  This  time  when  sl.l  is  assigned  tod2  he  finds  out  that  the  module  .Ma.1.1  has  to  be  re- 
decomposed.  The  new  decomposition  keeps  Oa  after  modifying  it.  adds  a  new  component  Of.  and 
deletes  Ob.  Now  dZ’s  private  workspace  includes  the  modified  components  Oa.spec.  1  1 .  Of  spec 
and  Of  imp  (n»*w  components  do  not  have  version  or  variation  numbers  yet)  When  d2  commits  his 
'tep.  using  the  commit_Ntep  command.  The  following  actions  take  plate 

a.  The  modified  component  Maspec.1.1  (the  primary  mputi  is  tonticure.; 
(calculates  its  version  and  variation  numberi  as  Ma.spec  1.2.  and  added  to  the  configuration  graph 
I  shared  data  space) 
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part  of  &  used^by  (components 


b.  The  modified  components  Oa.spec.1.1,  Of.spec,  Of.imp  are  committed  as 
Oa.spec.1.2,  Of.spec.  1.1,  and  Of.imp.  1.1.  Two  proposed  steps  are  created  with  primary  inputs 
Oa.spec.  1 .2,  Of.spec.  1 . 1  respectively. 

c.  Committing  s  1 . 1  requires  d2’s  interaction  to  change  the  .secondary  input  set  to  si  .3 
to  include  Of.spec.  1 . 1  and  delete  Ob.spec.  1.1. 

d.  When  the  top  level  step  si  commits  later,  the  part.of  relation  of  the  new  version 
Mu.  1.2  .should  be  modified  to  include  Oa.1.2,  Of.  1.1,  and  exclude  Ob.  1.1  as  shown  in  Figure  16. 

6.  Assessment  of  the  Adequacy  of  the  Proposed  Command  Set 

To  assess  the  adequacy  of  the  proposed  command  set  for  the  purpose  of  the  ECS,  we  walk 
through  the  different  functions  and  operations  required  by  the  system  and  check  whether  the  given 
command  set  is  sufficient  to  perform  each  one  of  them.  The  best  way  to  do  that  is  to  start  from 
scratch  where  we  have  no  prototype  in  the  environment.  The  create_prototypc  command  enables 
both  the  manager  and  the  designer  to  create  new  prototypes  with  unique  names  as  a  logical  first 
step.  The  evolution  of  this  prototype  is  done  via  evolution  steps.  The  creation  of  such  steps  is  done 
using  the  create_step  command  which  leads  to  a  creation  of  a  step  in  the  proposed  state.  The 
management  control  over  ongoing  evolution  activities  is  enforced  via  the  approve_step  command. 
This  command  controls  the  steps  accepted  for  the  system’s  consideration,  and  gives  the  manager 
the  ability  to  enter  and  update  the  management  constraints  (precedence,  priority,  deadline,  and 
estimated.duration)  as  well  as  the  step  attributes  (primary,  secondary,  and  affected  modules)  via 
the  corresponding  commands  updatc_precedtiice,  update_priority.  update_deadline, 
update_estimated_duration.  add/delete  primary_input.  secondary_input.  and  affcctcd_modules. 
The  schedule_stcp  command  is  a  manager  command  for  incremental  planning  of  approved  steps 
vkhen  they  become  available  either  after  fulfillment  of  its  management  constraints  or  having  a 
budget  to  implement  it.  The  continuous  control  of  the  manager  over  the  steps  in  progress 
(scheduled  or  assigned)  is  guaranteed  via  the  suspend_stcp,  and  abandon_stcp  commands  that 
enable  him  to  suspend  a  step  and  get  it  back  to  the  approved  state  or  abandon  the  step  completely 
as  dictated  by  various  management  situations.  The  manager's  confirmation  is  also  a  condition  to 
any  automated  system  decisions  concerning  suspending  a  step  according  to  a  ness  dependency 
inserted  into  the  system,  or  slipping  a  deadline  to  get  a  feasible  schedule.  The  manager  in  both 
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previous  cases  is  given  the  choice  to  either  confirm  the  system  decision  or  use  the  set  of  edit 
commands  at  hand  to  adjust  various  attributes  of  the  step  or  the  management  constraints  to  reach 
a  decision  that  accurately  reflects  the  management’s  concerns.  The  set  of  commands  add_designer, 
drop.designcr,  and  designer_expertise_level  enables  the  manager  to  control  the  designer  pool. 

Designers  tasks  are  streamlined  with  the  ECS.  The  designer  interface  has  two  main 
commands.  The  create_step  and  commit_step  commands  enable  him  to  create  a  step  according  to 
prototype  demonstration  feedback  or  a  change  request  from  the  customer  site,  and  to  commit  his 
completed  work  of  his  assigned  step  without  having  to  worry  about  the  versioning  of  his  committed 
components  since  the  version  and  configuration  control  are  transparent  to  him.  The  designer  does 
not  need  any  other  commands  since  the  system  sends  to  his  private  workspace  all  the  data  required 
to  do  his  task  including  the  primary  and  secondary  inputs  of  the  step. 

7.  Questions  and  Design  Decisions 

1.  Is  the  designer  responsible  for  a  composite  step  also  responsible  for  its  sub-steps? 

No.  otherwise  each  top  level  evolution  step  must  be  done  by  a  single  designer.  This  is  not 
acceptable  because  team  effort  must  be  supported  for  rapid  updates. 

2.  Can  the  ECS  assign  more  than  one  step  to  the  same  designer  at  the  same  time? 

No.  The  main  reason  for  not  doing  that  is  to  minimize  the  development  time  via  maximum 
concurrency.  This  goal  could  only  be  reached  if  we  let  each  designer  concentrate  on  one  task  and 
get  it  done  in  the  minimum  time  to  enable  the  system  to  assign  more  tasks.  This  is  due  to  the  fact 
that  a  step  can  only  be  assigned  if  it  is  atomic  or  if  all  the  steps  it  depiends  on  are  committed.  This 
guarantees  the  consistency  of  the  software  system  via  change  propagation  and  minimized  roll¬ 
backs. 

3.  Is  keeping  a  step  history  (recording  the  sequence  of  versions  of  an  edited  step)  of  value  to 
the  design/prototyping  process? 

Yes,  this  may  help  in  tracing  changes  to  a  step,  determining  what  kind  of  change  to  a  step 
are  most  likely  to  happen,  the  effect  of  each  kind  of  change  on  the  system  releases  and  deadlines, 
and  accordingly  help  decide  what  kinds  of  step  editing  should  be  permitted;  e.g.  avoid  step  editing 
that  has  adverse  effects  on  step  completion.  The  main  uses  of  this  information  are  to  improve  the 
tools  and  process  guidelines,  and  to  evaluate  the  abilities  of  managers  and  designers.  This  capabil- 
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ity  would  not  be  used  directly  in  the  operation  of  the  ECS.  For  this  reason,  we  do  not  consider  it 
further  in  our  requirements  and  design. 
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IV.  DESIGN  DEVELOPMENT  OF  ECS 


A.  MODELING  THE  DESIGN  DATABASE 

The  data  in  the  design  database  includes  all  the  components  of  the  ECS  state  as  given 
by  the  functional  specifications  in  Chapter  IIl.F,  and  Appendix  A.  1 .  These  components  are; 
the  configuration  graph,  the  current  schedule,  and  the  designer’s  pool.  The  configuration 
graph,  G=[C,  S,  CE,  SE.  I,  O],  consists  of  two  sets  of  nodes,  C  and  S,  the  software 
component  nodes  and  evolution  step  nodes,  and  four  sets  of  edges.  CE,  SE,  I,  and  O,  the 
different  kinds  of  edges  representing  the  relations  between  pairs  of  evolution  graph  nodes 
component-component,  step-step,  component-step  and  step-component  respectively.  The 
design  database  (DDB)  schema  as  well  as  the  mapping  between  the  components  of  the  ECS 
state  model  to  this  schema  is  presented  in  the  rest  of  this  section.  The  imp'ementation 
details  of  this  schema  using  Ontos  database  [63]  is  given  in  Appendix  B.  The  Ada  interface 
to  the  design  database  schema  which  contains  the  definition  of  an  Ada  package  (both 
specification  and  body)  that  enable  the  main  ECS  program  (in  Ada)  to  access  the  shared 
data  in  the  design  database  according  to  the  DDB  schema,  is  given  in  Appendix  C.  1 . 

1.  Design  Database  Schema 

The  main  types  defined  in  our  database  schema,  shown  in  Figure  20,  are: 

1.  Object:  represents  the  persistence  property. 

2.  Version:  a  subtype  of  type  Object  to  represent  immutable  versions  of  software  objects. 

3.  Component:  a  subtype  of  type  Version  to  represent  the  component  decomposition  of  a 
prototype. 

4.  Top_componcnt:  a  subtype  of  type  Component  to  represent  prototypes. 

5.  Step:  a  subtype  of  type  Version  to  represent  software  evolution  steps. 

6.  Top_step:  a  subtype  of  type  Step  to  represent  top  level  evolution  steps. 

7.  Designer;  a  subtype  of  type  Object  to  represent  designer  information. 

8.  Assignment:  a  subtype  of  type  Object  to  represent  a  schedule  record. 

9.  Text_Object;  a  subtype  of  type  Object  to  represent  software  component  text. 
lO.Sequencer:  subtype  of  type  Object  to  generate  sequential  numbers. 
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Top  level  evolution  steps  and  their  substeps  are  represented  by  instances  of  the 
types  Top.step  and  Step  respectively.  The  steps  are  represented  in  the  database  as  a  set  of 
Step  object  with  a  sequencer  object  associated  with  this  set  to  produce  a  unique  step_id  for 
each  created  step.  Prototypes  and  their  components  are  represented  by  instances  of  the 
types  Top.component  and  Component  respectively,  and  each  defined  versioned 
component  has  a  corresponding  Sequencer  to  keep  track  of  the  number  of  variations 
splitted  for  each  component  The  designer  pool  is  represented  by  a  set  of  instances  of  type 
Designer  while  the  schedule  is  represented  by  a  list  of  instances  of  type  Assignment  The 
set  of  text  files  (.spec,  .imp,  .ps.  .graph,  and  .a)  belonging  to  each  component  are 
represented  by  instances  of  type  Text_Object  The  abstract  representations  of  the  different 


types  are  defined  in  the  following  subsections. 


FIGURE  20.  Type  hierarchy 

a.  Type  Object 

The  type  object  is  the  most  general  type.  All  other  types  are  either  directly  or 
indirectly  subtypes  of  type  object  All  instances  of  t)!^  object  are  persistent  by  definition. 
This  means  that  entities  that  are  created  by  an  operation  persist  beyond  the  lifetime  of  this 
operation. 
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Type:  object  supenype:  None 

Properties:  persistent 

Name:  string 

Operations; 

getObject 

putObject 

Both  of  these  operations  takes  an  object  name  as  an  input  and  returns  a  pointer 
to  an  object  or  saves  an  object  in  DDB  respectively. 

b.  Type  Version 

All  evolving  objects  arc  directly  or  indirectly  subtypes  of  the  type  version. 
This  type  as  well  as  its  subtypes  are  immutable  versions  of  software  source  objects  that 
cannot  be  reconstructed  automatically  such  as  source  code  modules,  specification  modules, 
requirement  modules,  and  evolution  steps.  Type  version  has  the  following  abstraction: 

Type:  version  Supertype;  object 

Properties: 

versionjd  :  natural 

variationjd  :  natural 

prcvious_vcrsion  :  version 

ncxt_vcrsion  :  version 

timc_created  :  time 

Operations: 

gct_prcvious_vcrsion 

gct_ncxt_vcrsion 

These  two  operations  are  used  for  history  tracking  as  well  as  for  the  merge 
process  to  locate  a  common  base  version  for  a  set  of  merging  components.  Each  of  these 
operations  takes  an  object  name  as  an  input  and  returns  a  pointer  to  the  previous  or  next 
version  of  this  object. 
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c.  Type  Component 

This  type  is  the  specification  of  type  version  for  the  immutable  software 
components  mentioned  in  type  version  above.  Each  instance  of  this  type  represents  a  frozen 
version  of  a  software  component 

Type:  component  Supertype:  version 

Properties: 

created_by  :  name 

part_of  ;  set  {component) 

subcomponents  :  set  {component) 

used_by  :  set  {component) 

data  :  text  (represents  component  data) 

-  list  of  text  files  (.spec,  .imp,  .ps,  .graph,  and  .a  files) 

Operations: 

create_component 

retrieve_component 

show_components 

The  operation  create  component  r  ?.  •nmponent  name  as  an  input  and 
creates  an  oL^  -t  ±  -.o  nair-e  in  the  design  database  (if  this  component  does  not  exist  in 
the  current  working  directory  of  the  DDB),  it  also  adds  the  different  text  files  from  the 
designer  workspace  as  the  data  of  this  object  and  it  also  assigns  a  version  and  variation 
number  to  the  newly  created  object.The  operation  show_components  is  a  directory  like 
listing  of  the  component  and  its  subcomponents,  while  the  operation  rctrieve_component 
includes  copying  the  component  to  a  specified  workspace. 

d.  Type  Topjcomponent 

top_component  is  a  component  that  is  not  part  of  any  other  component.  This 
type  is  used  to  represent  prototype  configurations  and  to  enable  distinguishing  prototypes 
as  a  separate  class  to  optimize  their  access  time.  This  separation  enables  the  iteration  over 
the  top.component  (s)  without  having  to  iterate  through  all  the  components  to  locate  only 
the  top  level  ones. 
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Name 


vcrsion_id 

variation_id 

prcvious_version 

ncxt_version 

timc.created 

creatcd.by 

part_of 

subcomponents 
used_by 
Data  (test  files) 


FIGURE  21.  Component  attributes 


Type  top.  component  Supertype:  component 
Properties: 

part_of:  { } 


€.  Type  Step. 

A  steps  is  the  evolution  history  node  that  has  all  the  informations  required  to 
evolve  a  software  component  from  one  version  to  the  next  Each  instance  of  this  type 
represents  an  evolution  step  or  substep,  composite  or  atomic.  The  type  step  is  a  persistent 
object 

Type;  step  Supertype;  version 
ffroperties: 

primary.input 
secondary_input 
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:  set  (component) 
:  set  (component) 


Step. 


stcp_id 

primaryjnput 

secondary_input 

affected_modulcs 

output 

pait_of 

subcomponents 

status 

required_expcrtisejevcl 

deadline 

estimated.duration 

start^time 

finish_tinie 

priority 

precedcd.by 

designer 

date.created 

date_current_status 


FI(;URE  22.  step  attributes 

output  :  set  j  component  | 

part_of  ;  set  (step) 

status  ■  enumeration 

required_expcrtise_level  :  enumeration 

deadline  :  time 


79 


estimated.duration  ;  natural  (in  hours) 

estimated_start_time  :  time 

cstimatcd_finsh_timc  ;  time 

priority  ;  natural 

preccdcd_by  ;  set  j  step ) 

designer  :  name 

date_creatcd  ;  date 

date_of_cunent_status  ;  date 

Operations: 

create_step 

show_steps 

show_step_details 

update_step 

The  operation  CTeate_step  takes  a  prototype  name  (with  variation  and  version 
numbers)  as  a  base  version  and  a  component  name  as  primary  input  and  creates  step  with 
a  unique  number.  The  operation  update_step  takes  step  number  and  arbitrary  number  of  the 
step  attributes,  resets  the  single  valued  attributes  to  the  given  new  values  and  add  or  delete 
a  given  value  to  the  multivalued  attributes.  Show_steps  operation  takes  as  input  an 
identifier  of  a  certain  category  of  the  steps  (such  as  top,  proposed,  approved  .etc.)  in  the 
database  and  return  a  listing  of  those  steps.  Show_step_dctails  operation  takes  a  step 
number  as  an  input  and  returns  the  different  attributes  of  the  step. 

/.  Type  Topjstep 

This  type  is  used  to  distinguish  top  level  steps  from  their  substeps  to  enable 
the  iteration  over  the  top  steps  without  having  to  iterate  through  all  the  steps  to  locate  only 
the  top  level  ones. 

Type:  top_step  Supenype;  step 

Properties; 

part_of:  { ) 

affected_modules  :  set  (component} 


subcomponents 


;  set  { step ) 


Operations: 

show_substeps  (listing  of  the  substeps  of  the  step) 
g.  Type  Designer 

This  type  is  used  to  represent  a  designer's  dau  in  the  design  database.  The 
designer’s  pool  is  represented  by  a  set  of  instances  of  this  type. 

Designer 


Name  Expertiscjevel  Status 


FIGURE  23.  Designer  attributes 

Type:  designer  Supertype:  object 

Properties: 

name;  string 

expcrtisc_level;  cxpjcvcl 
status;  enumeration  { busy,  free ) 

Operations: 

add_designer 

delctc_designcr 

changc_expcrtisc_levcl 

change_status 

The  designer’s  operations  are  adding  new  designer  with  a  specified  expertise 
level  to  the  DDB,  deleting  a  designer  from  the  DDB,  and  changing  the  expertise  level  or 
the  status  of  an  existing  design  team  member. 


h.  Type  A  ssignment 

This  type  is  used  to  represent  the  relevant  information  of  assigning  a  step  to 
a  designer.  While  the  information  included  in  this  type  may  be  redundant  with  respect  to 
both  designer  data  in  the  designer’s  pool  and  corresponding  assigned  step,  this  type 
optimize  the  access  time  to  collect  such  information.  This  type  also  enables  saving  the 
planned  assignment  where  a  full  schedule  can  be  represented  as  a  list  of  instances  of  this 
type. 


Assignment 


Step_id  Designer_name  Estimated_start  Estimatcd_rinish 


FIGURE  24.  Assignment  attributes 

Type:  Assignment  Supertype:  object 

Properties: 

step_id  :  natural 

designcr_name  :  string 

estimatcd_start_time  :  t’me 

esumatcd_finsh_time  ;  time 

Operations: 

create  Assignment 
deleteAssignment 
showAssignment 

L  Type  Schedule 

An  instance  of  this  type  represent  the  full  schedule  gen'  jted  by  the  scheduler 
to  be  kept  in  the  database. 

Type:  Schedule  Superiypc:  object 

Properties; 
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Assignments  ;  List  (Assignment) 

Operations: 

createScheduIe 

deleteScheule 

showScheduIe 

The  schedule  uses  a  list  as  a  container  class  for  the  assignments  to  enforce  any 
ordering  required  over  the  schedule  assignments. 

j.  Type  Sequencer 

Instances  of  this  type  are  used  as  persi.stent  counters  where  needed.  An 
instance  of  this  type  is  needed  for  each  versioned  object  to  keep  track  of  the  number  of 
variations  for  each  object.  An  instance  of  this  type  is  also  used  to  keep  track  of  the  number 
of  steps  created  and  to  be  used  for  steps  unique  numbering. 

Type:  Sequencer  Supertype:  object 
Properties: 

Value  :  natural 

Operations: 

getValue 

IncrementValue 

This  is  the  only  two  operations  needed  on  a  sequencer  and  they  can  be 
implemented  as  one  since  any  time  the  value  is  needed  it  has  to  be  incremented. 

k.  Type  TextjObject 

Instances  of  this  type  are  used  to  represent  different  files  associated  with  each 
component  in  the  design  database. 

Type:  Text_Object  Supertype:  object 
Properties: 

Name  :  string 

Value  :  Text 

Operations: 

creatcTextObject 
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R_rctricvcTcxtObjcct 

W_retrieveTcxtObjcct 

getTextObjecNamc 

The  operation  createTextObject  is  used  to  create  a  text  object  that  has  the 
name  of  the  input  text  file  and  its  value  is  equal  to  the  text  of  the  file.  The  operations 
R_retrieveTextObject  and  W_retrieveTextObject  are  used  to  get  the  text  object  from  the 
database  in  read  only  mode  or  read/write  mode  respectively.  The  last  operation 
getTextObjecName  is  used  to  list  the  names  of  the  text  objects  included  in  a  component 

2.  Concurrency  Control 

Concurrency  control  is  one  of  the  problems  in  the  field  of  database  management 
that  has  received  much  discussion  and  many  solutions.  Most  of  these  solutions  are  based 
on  two  basic  assumptions.  First,  all  the  transactions  must  be  executed  such  that  their  results 
are  equivalent  to  some  serial  execution  of  those  transactions.  Second,  objects  have  a  single 
value.  In  some  of  these  solutions  old  versions  are  used  for  a  short  period  of  time  as  a 
transient  states,  but  when  the  transaction  completes  the  values  of  the  old  versions  are  not 
retained  [85]. 

In  the  context  of  software  evolution/development  all  old  versions  of  an  object  are 
made  available  via  the  version  control  mechanism.  This  contradict  the  second  assumption 
due  to  the  nature  of  the  design  database,  where  a  version  of  an  object  cannot  be  modified 
but  can  be  read  at  any  time  (read-only).  This  makes  it  possible  for  readers  and  writers  to 
work  on  the  same  object  and  never  conflict  The  immediate  effect  of  this  is  an  increase  in 
concurrency  level  of  the  system. 

The  traditional  question  of  what  happens  when  two  steps  try  to  modify  the  same 
object  occurs  in  our  system  in  two  cases;  first,  when  the  designer/management  decides  to 
explore/start  another  alternative  which  automatically  splits  a  new  variation  of  the  original 
one  with  the  alternate  object  version  attached  to  it.  Second,  when  two  modifications  have 
to  be  done  to  the  same  object,  the  serialization  is  automatically  done  by  the  Evolution 
Control  System,  in  a  higher  level  of  abstraction,  which  takes  care  of  planning  these  changes 
to  be  serialized  according  to  a  predefined  management  policics.These  policies  should  not 
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permit  starting  one  of  the  steps  before  commining  the  other  one  according  to  the 
management  constraints  such  as  precedence,  and  deadlines. 

Figure  25  depicts  the  horizontal  view  of  the  graph  representation  of  the  relation 
between  system  versions  and  the  corresponding  evolution  steps.  Step  Sji  is  applied  to 
version  Vjj  of  a  software  object  (where  “k”  is  the  step  number,  “i"  repre.senLs  the  variation 
number  and  “j"  represents  the  version  number  along  one  variation)  producing  version 
Variations  are  represented  as  partial  paths  in  the  graph,  applying  step  "■ 
produces  the  version  on  the  same  variation  line.  Applying  step  81^+2  to 

produces  a  new  variation  i+1  with  version  Vj^|  j^2-  Applying  step  Si(+3  to  Vj  j  produces 
another  new  variation  i+2  with  the  version  Vi^2.j+l- 

The  graph  can  .also  include  dependencies  between  the  modified  versions  and 
versions  of  other  objects  tiiat  are  not  modified  by  the  step,  such  as  specifications  of  other 
modules.  For  simplicity  limes  of  this  type  are  not  shown  in  Figure  25. 

Notice  that,  in  case  of  a  split  that  creates  a  new  variation,  it  is  the  order  in  which 
the  step  is  assigned  rather  than  the  version  number  of  the  base  version  that  decides  the 
variation  number  (i.  e..  Step  k+2  created  the  new  variation  i+1  and  Step  k+3  created  the  new 
variation  i+2  despite  the  fact  that  the  first  is  applied  to  version  j+1  and  the  second  is  applied 
to  version  j).  Thus  the  variation  numbers  capture  the  chronological  order  in  which  the 
variations  were  created.  Step  numbers  are  assigned  in  increasing  order  when  the  steps  are 
created.  Steps  can  be  carried  out  concurrently  and  asynchronously,  and  the  order  in  which 
they  actually  start  or  complete  their  implementation  phases  can  differ  from  the  order  in 
which  the  steps  are  added  to  the  schedule. 

As  for  the  other  shared  components  of  the  ECS  such  as  the  designer-pool  and  the 
schedule,  the  modification  to  the  former  one  is  only  performed  by  the  design  manager  while 
the  later  is  subject  to  change  through  the  invoked  instances  of  the  designer_interface  to  ECS 
and  the  manager  interface.  For  these  components  we  rely  on  the  underlying  database 
concurrency  control  scheme  (Ontos  Database  in  our  implementation)  to  serialize 
concurrent  access  to  these  components  as  an  atomic  transactions. 
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FIGURE  25.  The  relation  between  system  versions  and  evolution  steps 


B.  IMPLEMENTATION  CONSIDERATIONS 

The  prototype  implementation  of  the  ECS  is  intended  to  be  on  unix  system,  where 
multiple  instances  of  ECS  are  run  concurrently  by  different  users  (managers  and  designers). 
These  instances  of  the  ECS  share  the  ECS  state  data  stored  in  the  DDB  as  defined  in  section 
A  above  by  the  DDB  schema  and  its  Ontos  representation  defined  in  Appendix  B. 


1.  Implementing  Shared  Data  for  Multiple  Users 

The  shared  data  by  multiple  ECS  users  consists  of  the  evolution  graph  (evolution 
steps  and  software  component  versions)  the  designer_pool  dau  and  the  schedule.  Despite 
the  fact  that  the  schedule  information  my  be  redundant  with  some  of  the  steps  attributes,  it 
is  stored  as  a  separate  component  to  optimize  the  access  to  the  schedule  informations  a 
collected  plan  of  a  project  implementation  and  to  enable  to  relate  different  scheduled  tasks 
to  each  other  with  respect  to  some  scheduling  attributes  such  as  start  time  or  expertise  level 
and  so  on.  The  design  database  in  the  ECS  implementation  consists  of  two  main  parts:  the 
first  part  is  the  shared  data  space  where  all  the  ECS  state  data  are  stored,  and  the  second 
part  is  the  designers  work  spaces  where  modification  to  software  components  arc 
performed.  ^ 

a.  Shared  Data  Space 

The  shared  data  space  is  the  repository  that  keeps  all  of  the  verified  software 
objects  (versions  or  configurations)  and  their  corresponding  evolution  steps.  The  versions 
in  the  shared  data  space  are  frozen  and  may  not  be  changed  under  any  circumstances.  Any 
changes  to  any  of  the  objects  must  be  done  in  the  context  of  an  evolution  step,  authorized 
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by  the  management,  and  completion  of  such  a  step  can  only  add  new  versions  to  the  shared 
data  space.  The  shared  data  space  contains  the  public  releases  of  the  software  objects. 
Mutable  copies  of  these  objects  can  only  be  obtained  as  part  of  an  evolution  step  controlled 
by  the  Evolution  Control  System.  The  relations  between  the  objects  in  the  database  are  kept 
as  attributes  of  each  object  and  the  corresponding  evolution  step. 

b.  Private  Workspaces 

Since  the  data  in  the  shared  data  space  is  frozen  and  may  not  be  changed,  the 
designers's  private  workspaces  arc  used  for  production  of  new  versions  of  existing  objects 
or  adding  new  objects  to  existing  software  systems  which  in  turn  produce  new  versions  of 
the  software  system.  A  designer’s  private  workspace  is  protected  from  updates  by  other 
designers  while  a  step  is  in  progress.  This  is  visible  via  the  other  CAPS  tools  and  has  no 
impact  on  the  observable  behavior  of  the  ECS  system. 

The  private  workspaces  have  the  following  relations  with  the  graph  model  for 
software  evolution: 

1.  There  is  a  1:1  correspondence  between  private  workspaces  and  evolution  steps.  This 
means  that  each  designer  can  only  be  assigned  one  step  at  a  time. 

2.  There  is  a  1:1  correspondence  between  objects  in  the  private  workspace  and  the  set  of 
objects  representing  the  inputs  to  and  the  outputs  from  the  step  of  the  workspace 
(inputs  (s)  U  outputs  (s):  where  s  is  the  step  of  the  workspace). 

3.  Only  the  output  objects  of  the  step  can  have  mutable  copies  in  the  private  workspace. 

4.  Secondary  inputs  of  the  step  have  immutable  copies  in  the  private  workspace 

The  process  of  copying  objects  to  and  from  the  designer’s  workspace  is  done 
automatically  by  the  Evolution  Control  System  (ECS),  and  these  objects  continue  to  be 
under  its  control  until  either  all  the  changes  are  done  and  the  ECS,  triggered  by  the 
commit_step  command  from  the  designer,  commits  them  to  the  shared  data  space 
producing  a  new  version  of  each  modified  object  (when  a  mutable  version  in  the  private 
workspace  is  committed  by  the  ECS,  it  becomes  an  immutable  version  in  the  shared  data 
space),  or  if  the  changes  are  suspended/abandoned  then  cunent  copies  of  completed 
mutable  versions  are  saved  as  an  attribute  to  the  step  for  future  reference. 
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2.  Choice  of  Languages  and  Support  Systems 


As  a  work  done  at  the  Naval  Postgraduate  School,  computer  science  department, 
we  do  not  have  much  of  choice  of  the  language  to  be  used  for  implementing  the  ECS 
system,  needless  to  say  this  language  had  to  be  Ada.  However,  the  support  object  oriented 
database  system  is  Ontos  database  [63]  [64]  that  has  its  interface  and  schema  written  in 
C>4-.  This  adds  the  burden  of  having  to  define  an  Ada  interface  package  that  lets  the  ECS 
Ada  program  access  the  shared  data  in  the  DDB  according  to  the  defined  DDB  schema. 
Ontos  DB  is  a  multi-user,  distributed  object  database  with  a  C++  class  library  interface  that 
provides  a  reliable  storage  facility  for  C-m-  objects.  It  has  standard  database  capabilities  and 
a  special  support  for  objects  as  well  as  a  set  of  database  and  object  oriented  classes 
enhancing  the  power  of  the  C++  language  [64]. 

3.  Software  Decomposition  and  Structure 

The  Evolution  Control  System  ECS  consists  of  two  main  modules,  the  manager 
interface  and  the  designer  interface.  The  manager  interface  includes  all  the  commands 
needed  to  implement  the  specified  behavior  of  this  interface  given  in  chapter  in.F  and 
Appendix  A.  These  commands  include  show_prototypes,  show_steps,  show_step_details, 
show_schedule,  create_prototype,  crcate_step,  edit.step,  edit_team,  approve  step, 
schedule_step,  commit_step,  suspend_step  and  abandon_step.  The  designer  interface 
includes  the  commands  needed  by  the  designer  to  execute  the  assigned  step  which  are 
create_substep,  commit_substep  and  the  adminstrative  commands  such  as 
show_prototypes,  show_steps,  show_stcp_details,  and  show_schedule.  The  Ada 
implementation  of  these  commands  as  defined  in  the  functional  specification  is  given  in 
Appendix  C. 

C.  THE  SCHEDULING  PROBLEM 

Our  problem  is  to  schedule  a  set  of  sporadic  tasks  (software  evolution  steps).  These 
sporadic  tasks  have  random  arrival  times,  and  given  deadlines,  precedence  constraints,  and 
priority  values  to  indicate  the  criticalness  of  their  deadlines.  Because  of  the  unpredictable 
nature  of  the  arrival  time  of  the  sporadic  tasks,  it  is  very  difficult  to  design  a  real-time  (on- 
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line)  system  that  guarantees  that  all  their  deadlines  can  be  met  |34|.  Morenver,  each  of  these 
tasks  requires  certain  expertise  level,  which  implies  that  the  system  model  is  a  set  of  M 
software  designers  of  different  expertise  levels  (not  identical  designers).  This  problem  is 
similar  to  that  of  dynamic  scheduling  tasks  with  arbitrary  arrival  times,  deadlines,  and 
precedence  constraints  in  a  multiprocessor  system  where  the  processors  are  not  identical. 

Hong  and  Leung  {34]  proved  that  there  is  no  optimal  on-line  scheduler  can  exist  for 
task  systems  that  have  two  or  more  distinct  deadlines  when  scheduled  on  m  identical 
processors,  where  m  >  1.  Scheduling  tasks  with  arbitrary  precedence  constraints  and  unit 
computation  time  is  NP-hard  both  the  preemptive  and  the  non-preemptive  ca.se  (67).  Our 
problem  is  even  more  complicated  than  both  of  the  above  two  cases,  when  contrasted  with 
the  case  proven  in  [34]  we  have  more  than  one  designer  and  each  step  of  the  step  set  has  its 
distinct  deadline  which  is  the  same  conditions  for  the  conclusion  reached  by  Hong  and 
Leung,  in  addition,  the  designers  are  not  of  the  same  expertise  level  which  makes  it  even 
more  complicated.  In  contrast  with  results  of  (67)  our  problem  includes  arbitrary 
precedence  constraints  between  pairs  of  the  steps  in  the  step  set  to  be  scheduled  in  addition 
to  an  arbitrary  compuution  time  for  each  step  which  makes  it  even  harder  than  the  ca.se  of 
having  unit  computation  time.  These  negative  results  indicate  the  need  for  hemistic 
approaches  solve  this  scheduling  problem. 

1.  The  Scheduling  Algorithm 

Scheduling  a  set  of  tasks  to  reach  a  feasible  schedule  is  a  search  problem,  where 
the  search  space  can  be  structured  as  a  search  tree.  The  root  of  this  search  tree  is  an  empty 
schedule,  an  intermediate  node  is  a  partial  schedule,  and  a  leaf  node  (terminal)  is  a  complete 
schedule.  Since  not  all  leaves  correspond  to  feasible  schedules,  it  might  cause  an  exhaustive 
search  to  find  one,  which  is  computationally  intractable  in  the  worst  ca.se.  Because  of  the 
computational  complexity  of  finding  a  full  feasible  schedule  in  many  of  the  real 
applications,  heuristic  approaches  are  used. 
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i.  System  and  T ask  Model 

The  task  set  in  the  ECS  scheduling  problem  is  a  variable  set  of  evolution  steps 

S  =  {Sj,  S2 . Sisj},  where  N  varies  with  time.  This  set  of  tasks  need  to  be  scheduled  to  a 

set  of  M  designers  D  =  ( Dj.  Do.....  j.  The  designers  are  of  L  different  expertise  levels. 
Tasks  (steps)  are  characterized  by  the  following; 

•  Estimated  processing  time  tp  (Sj):  a  management  estimate  of  the  time  required  to  per¬ 
form  a  step. 

•  Deadline  d  (Si):  The  time  by  which  a  step  must  be  completed 

•  Earliest  start  time  EST  (Sj);  the  earliest  time  at  which  the  step  can  be  assigned  to  a 
designer  (calculated  when  a  scheduling  decision  is  made). 

•  Priority  p  (Sj):  An  integer  value  to  reflect  the  criticalness  of  the  deadline  of  a  step. 

•  Resource  requirement  r  (Sj):  required  expertise  level  for  performing  a  step. 

•  Precedence  constraints  given  in  the  form  of  a  directed  acyclic  graph  G  =  (S.  E)  such 
that  (Sj,  Sj)  €  E  implies  that  Sj  cannot  start  until  Sj  ha^  been  completed. 

In  order  to  support  teamwork,  we  assume  that  each  step  is  assigned  to  a  single 

designer.  This  designer  must  have  at  least  the  same  expertise  level  as  that  of  the  step.  We 

also  define  the  earliest  start  time  EST  (Si)  as  the  earliest  time  at  which  the  step  can  be 

assigned  to  a  designer.  This  dme  is  calculated  when  a  scheduling  decision  is  made. 

Our  goal  is  to  determine  whether  there  exists  a  schedule  for  executing  the 

tasks,  that  satisfies  the  timing,  precedence,  and  resource  constraints,  and  to  calculate  such 

a  schedule  if  one  exists.  Since  this  problem  is  computationally  intractable,  we  weaken  the 

requirements  to  checking  whether  a  feasible  schedule  can  be  found  within  the  available 

time.  Otherwise  advise  the  software  manager  of  the  lowest  priority  deadlines  that  have  to 

be  canceled  (moved  to  their  calculated  finish  time)  in  order  to  get  a  feasible  schedule.  This 

algorithm  should  also  give  the  software  manager  the  choice  to  change  other  constraints 

such  as  priority,  precedence  or  estimated  execution  time  of  the  tasks  to  tune  the  schedule 

each  time  new  evolution  steps  are  to  be  added  to  the  schedule  and  a  feasible  schedule 

cannot  be  reached.  It  also  must  check  the  validity  of  these  changes  (e.g.  if  a  priority  of  a 

step  is  changed  it  has  to  be  less  than  or  equal  the  priorities  of  its  predecessors  and  greater 

than  or  equal  to  that  of  its  successors). 
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Thus,  we  need  an  on-line  scheduler  that  is  called  when  one  or  more  sporadic 
tasks  arrive  at  time  t  (new  tasks  in  our  system  may  have  some  of  the  constraints  not  defined 
when  they  arrive  to  the  scheduler)  or  if  the  attributes  of  the  currently  scheduled  tasks 
change,  to  decide  if  the  newly  anived  tasks,  or  the  changed  tasks,  along  with  unassigned 
tasks  at  time  t  (scheduled  but  not  started  yet),  could  be  rescheduled  so  that  all  deadlines  are 
met.  If  a  feasible  schedule  is  reached  the  system  will  continue  assigning  the  tasks  to  the 
designers  according  to  the  schedule  constructed  by  the  on-line  scheduler.  Otherwise  the 
system  will  try  to  meet  the  deadlines  of  the  most  important  (highest  priority)  tasks  and 
suggest  changing  the  deadlines  of  the  least  important  ones.  These  suggestions  could  be 
accepted  by  ihe  manager  or  he  can  change  other  parameters  which  in  turn  triggers  the  on¬ 
line  scheduler  to  recalculate  the  schedule  accordingly. 

Changing  the  attributes  of  currently  scheduled  tasks  means  editing  any  of  the 
constraints  of  the  not-started-yet  tasks,  assigned  tasks  that  are  prone  to  exceed  their 
estimated  execution  time  (which  is  a  common  case  in  software  effort  estimation),  and  the 
addition/deletion  of  designers. 

b.  A  Heuristic  Search  Scheduling  Algorithm 

A  heuristic  scheduling  algorithm  tries  to  reach  a  feasible  schedule  for  a  set  of 
tasks  by  starting  at  the  root  of  the  search  tree,  which  is  an  empty  schedule,  and  tries  to 
extend  the  schedule  with  one  more  task  by  moving  to  one  of  the  nodes  in  the  next  level  of 
the  search  tree  until  a  feasible  schedule  is  reached.  The  nodes  in  the  next  level  of  the  search 
tree  consist  of  those  tasks  that  are  ready  to  be  scheduled,  i.e.  the  tasks  that  have  all  their 
predecessors  completed  at  this  point  or  has  no  predecessors.  A  partial  search  path  is 
extended  only  if  it  is  strongly  feasible.This  is  because  if  extending  the  current  schedule  by 
a  task  T  causes  T  to  miss  its  deadline  then  none  of  all  the  possible  future  extensions  can 
meet  the  deadline  of  task  T,  since  starting  T  later  cannot  make  it  finish  earlier  [67].  To  this 
point  we  introduce  the  following  definition: 

•  Strongly-feasible  partial  schedule:  A  partial  schedule  is  strongly-feasible  if  all  .sched¬ 
ules  reached  by  extending  it  by  any  of  the  remaining  (ready  to  be  scheduled)  tasks  are 
also  feasible. 
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If  the  partial  schedule  is  strongly  feasible  then  a  heuristic  function  is  used  to 
extend  the  partial  schedule.  This  heuristic  function  should  reflect  various  characteristics  of 
the  scheduling  problem  to  effectively  direct  the  search  to  a  plausible  path.  If  all  the 
schedules  resulting  from  extending  the  cunent  schedule  with  any  of  the  remaining  tasks  are 
also  feasible,  the  partial  schedule  is  called  strongly  feasible.  The  heuristic  function  is  then 
applied  to  every  task  that  is  ready  to  be  scheduled.  The  task  with  a  predefined  property  of 
the  heuristic  function  is  selected  to  extend  the  current  partial  schedule  (e.g.  if  we  use  the 
earliest  deadline  first  as  our  heuristic  then  we  pick  the  task  with  earliest  deadline  of  the 
tasks  that  are  ready  to  be  scheduled  to  extend  the  cunent  partial  schedule),  otherwise  this 
search  path  is  stopped  because  it  will  not  lead  to  a  feasible  schedule. 

Our  heuristic  algorithm  is  based  on  the  heuristic  algorithm  introduced  in  [67] 
and  discussed  above.  The  main  difference  is  that  the  tasks  in  our  problem  have  precedence 
constraints  which  is  not  discussed  in  [67]  where  the  authors  deal  with  a  set  of  independent 
usks.  Another  difference  is  that  each  task  has  its  own  deadline  rather  than  a  common 
deadline  for  each  set  of  tasks  as  is  the  case  in  [67J. 

Before  describing  the  details  of  our  algorithm,  let  us  introduce  the  following 

definitions. 

•  Pending_step;  a  step  whose  predecessors  (in  the  dependency  graph)  have  all  been 
scheduled  (not  necessarily  assigned  yet)  and  their  estimated  finish  time  is  calculated. 
The  step’s  earliest  start  time  is  set  to  the  latest  finish  time  of  its  predecessors. 

•  Ready_step;  a  pending  step  whose  earliest  start  time  is  less  than  or  equal  the  current 
time  t. 


The  following  data  structures  and  variables  are  used  by  the  algorithm; 

•  Dependency_graph;  a  directed  acyclic  graph  G  =  (S,  E)  such  that  S  =  ( S  i .  S2 . |  is 

the  set  of  steps  to  be  scheduled,  E  is  the  set  of  edges  such  that  (Sj,  Sj)  e  E  if  and  only  if 
Sj  cannot  start  until  Sj  has  completed. 

•  In_dcgree:  an  integer  representing  the  number  of  the  immediate  predecessors  of  each 
node  (step)  in  the  dependency  graph. 

•  Pending_list:  a  list  holding  pending  steps  sorted  in  a  non-decreasing  order  of  their  earli¬ 
est  start  time. 

•  Ready_list:  a  list  holding  ready  steps  sorted  in  a  non-decreasing  order  of  the  heuristic 
function  used  (e.  g.,  deadlines,  earliest  start  time  etc.). 
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•  Earliest  Ava.idbic  Time  (EAT);  a  vector  of  M  values  to  represent  tiic  earliest  available 
times  of  uie  resources  (designers).  EAT,  is  the  earliest  time  when  D,  becomes  available 
when  the  system  has  only  one  instance  of  each  resource  type  (expertise  level),  c.  g.,  for 
the  case  of  having  only  three  expertise  level  low.  medium,  and  high  and  one  designer  of 
each  level  then  EAT  =  (EATj  EAT,n  EAT^).  In  case  of  having  multiple  instances  of  each 
expertise  level  the  EAT  is  represented  as  a  matrix  so  that  each  row  represents  the  Earli¬ 
est  Available  Times  of  the  different  instances  of  each  expertise  level. 

EAT  =  ((EAT|i  EAT12  ..  EATik) 

(EATtui  E.vT,y,2 ..  EAT^^f) 

(EAThi  EATh2 ..  EAThp)) 

where  1,  m,  h  are  the  three  expertise  levels  low.  medium,  and  high 
respectively,  and  k,  r,  and  p  are  the  corresponding  number  of  designers  in  each  level. 

The  main  idea  of  th’S  algorithm  is  to  extend  the  current  schedule  by  one  of  the 
steps  in  the  ready  list.  The  tasks  in  the  ready  list  can  be  seen  as  independent  tasks  if  we  can 
define  an  earliest  start  time  and  a  deadline  for  each  of  them.  This  is  done  for  the  deadlines 
by  propagating  them  from  the  terminal  to  the  root  nodes  in  the  dependency  graph. 

The  propagated  deadline  d‘(Si)  of  a  step  Si  is  defined  by: 

1)  d’(Si)  =  d(Si)  if  -i3  Sj ;  Si  precedes  Sj 

or 

2)  d’(Si)  =  min  {d(Si),  d’(Sj)  -  tp  (Sj)}  V  ,Sj :  Si  precedes  Sj 

In  2)  above,  if  there  exists  some  step  Sj  such  that  Si  precedes  Sj  then  Sj  cannot 
Stan  until  Si  has  completed.  In  order  to  complete  Sj’s  computation  before  its  deadline,  the 
latest  time  by  which  Sj  must  be  started  is  d’(Sj)  -  tp  (Sj).  Then  Si's  real  deadline  should  be 
d’(Sj)  -  tp  (Sj)  if  it  is  smaller  than  d  (Si). 

As  for  the  earliest  start  time  (EST)  of  each  step,  it  is  adjusted  according  to  the 

following: 

1)  EST'  (Si)  =  EST  (Si)  if  -i3  Sj ;  Sj  precedes  Si 

or 

2)  EST’  (Si)  =  max  { EST  (Si),  EST'(Sj)  +  tp  (Sj) )  V  Sj ;  Sj  precedes  Si 


93 


In  2)  above,  if  there  exists  some  step  Sj  such  that  Sj  precedes  Si  then  Si  cannoi 
start  until  Sj  has  completed.  Since  the  earliest  time  that  Sj  can  be  completed  is  EST  (Sj)  >■ 
tp  (Sj)  then  Si's  real  EST  should  be  EST*(Sj)  +  tp  (Sj)  if  it  is  greater  than  HST  (Sii 

The  rea.son  for  having  ;»  pending_Iist  and  a  ready_lisi  instead  of  having  one 
ready_list  is  to  give  the  available  •  (in_degrce  =  0  and  EST  cunent  time)  a  fair 
chance  to  compete  foi  available  dcs.^.ners  especially  when  using  different  heuristics  other 
than  EST  first,  since  the  .scheduler  osiders  only  the  steps  in  the  ready _ list. 

Our  scheduling  algonnm.  has  two  different  initialization  procedures  The 
first  one  is  used  when  the  system  staits  from  scratch  (i.e..  the  schedule  is  empty),  while  the 
second  initialization  procedure  is  used  when  new  ta.slcs  arrive  at  the  system  or  some  of  the 
attributes  of  an  existing  step  is  changed.  This  scheduling  algorithm  is  similar  to  the  branch 
and  bound  technique.  The  strong  feasibility  check  done  before  extending  the  schedule  by 
another  node  in  the  search  tree  is  used  instead  of  the  lower  bound  check,  normally  used  with 
branch  and  bound  algorithm,  to  bound  the  search  in  a  given  search  path  The  algonthm 
works  as  follows: 

Initialization_part: 

(1)  if  initial_.schedule  =  empty 

(2)  then 

initialize  EAT  values  to  TO.  and  the  schedule  to  empty, 
pwrform  a  Depth  First  Search  on  the  dependency  graph  to: 

-  initialize  the  in_degree  for  each  node  (number  of  immediate  predecessors), 

-  propagate  deadlines,  and 

-  initialize  the  ESTs  (earliest  .start  time)  of  the  steps  that  have  no  EST  to  TO. 

insert  each  pending  step  (its  in_degree  =  0)  into  the  pending  list  ordered  by  its 
EST. 

(3)  else 

update  the  depcndency_graph: 

-  Remove  the  assigned  steps  and  their  corresponding  arcs  from  the  dependency 
graph 
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-  Add  the  newly  arrived  steps  to  the  dependency  graph  (if  there  is  any)  check¬ 
ing  for  the  “acyclic”  property  of  the  graph  and  the  compacibilitv  of  the  newly 
added  steps’  priorities  with  that  of  their  successors  and  predecessors  and  warn 
the  nunager  of  any  violation 

Recalculate  the  in.degree  of  the  graph  nodes. 

Re-initialize  the  EAT  vector  (matrix)  to  the  finish  time  of  the  step  assigned  to  each 
designer  and  to  t  for  the  free  designers. 

Insert  each  pending  step  (its  in_degree  s  0)  into  the  pending  list  ordered  by  its 
EST. 

end  if 

Scliedule_part: 

(4)  While  fuILschedule  is  not  reached  loop 

(5)  For  all  the  steps  in  the  pending  list: 

if  EST  (S)  <=  min(EAT)  of  the  corresponding  designers  then 

insert  S  into  the  ready  Jist  in  order  of  non-decreasing  values  of  the  H  (heu¬ 
ristic)  function  used  and  delete  S  from  the  pending  list. 

(6)  end  for 

(7)  While  readyjist  is  not  empty  loop 

(8)  if  not  STRONGLY_FEASIBLE  to  extend  the  schedule  by  each  of  the  steps 
in  the  rcadyjist  then 

if  the  backtrack  limit  is  not  reached  then  increment  backtrack 
counter  and  backtrack  (discard  the  current  partial  schedule  and 
backtrack  to  the  previous  partial  schedule  and  extend  it  by  a  dif¬ 
ferent  step) 

else  exit  (NO_FEASIBLE_SCHEDULE) 
end  if 

end  if 

(9)  extend  the  hedule  by  the  step  S  that  has  min  H 

in  case  of  ties,  select  the  step  Si  with  the  highest  priority,  then  the  step  with 
max  tp(Si) 

( 1 0)  update  the  EAT  of  the  assigned  designer 

(11)  update  the  EST  of  the  immediate  successors  of  S 

( 1 2)  decrement  the  in_degree  of  the  immediate  successors  of  S 

(13)  if  the  in_degree  of  any  of  the  immediate  successors  of  S  =  0 
then 

insert  it  into  the  pending_list  in  order  of  its  EST, 
end  if. 

delete  S  from  the  rcady_list 


(14) 


(15)  end  while 

(16)  end  while 

The  STRONGLY_FEASIBLE  is  a  boolean  function  that  works  as  follows: 

FEASIBLE  =  TRUE 

for  all  the  steps  S  in  the  ready_list  loop 

if  min  (EAT)  of  the  designers  of  the  same  or  higher  expertise  level  than 
level(S)  +  Estimated_duration(S)  >  deadline(S) 
then  FEASIBLE  »  FALSE 
end  if 
end  for 

The  following  are  some  of  the  heuristics  that  may  be  used  with  this  algorithm: 

•  Minimum  deadline  first  (Min_d):  H(S)  =  d  (S) 

•  Minimum  earliest  start  time  first  (Min_est):  H(S)  =  EST  (S) 

•  Minimum  laxity  first  (Min_L):  H(S)  =  d  (S)  -  (EST  (S)  +  tp  (S)) 

•  Min_d  +  Min.est  first:  H(S)  =  W  •  d  (S)  +  (I-W)  *  EST  (S) 

•  In  the  four  cases  ties  are  broken  using  the  priorities  of  the  steps  (the  highest  priority 
step  starts  first).  Further  ties  are  broken  by  selecting  the  step  that  has  the  maximum  tp. 

The  first  three  heuristics  are  simple  heuristics  and  the  last  one  is  an  integrated 

heuristic.  The  weight  W  (0  <®  W  <=  1),  used  to  combine  the  two  simple  heuristics  Min_d 

and  Min.est,  can  be  tuned  according  to  the  criticalness  of  the  deadlines  of  the  available 

steps.  This  means  if  the  deadlines  are  not  critical  then  W  can  be  set  to  0  which  leads  to 

Min.est  heuristic  that  is  the  best  for  team  work  to  assign  tasks  to  designers  according  to 

their  earliest  start  time  making  a  full  use  of  the  human  resources.  (}n  the  other  hand  the 

value  of  W  can  be  chosen  to  favor  the  deadline  heuristic  or  some  way  in  between  to  meet 

the  critical  deadlines  and  make  the  best  use  of  the  human  resources  (designers)  available. 

The  backtracking  limit  is  left  open  in  the  cases  where  the  number  of  tasks  is 

relatively  small,  and  is  limited  otherwise.  In  the  cases  where  no  feasible  schedule  is  reached 

either  due  to  the  absence  of  a  feasible  schedule  for  the  given  set  of  tasks  or  due  to  reaching 

the  backtracking  limit  of  the  algorithm  without  reaching  one,  an  algorithm  for  adjusting  the 
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deadlines  is  used.  This  enhancement  to  the  nlgorithm  is  presented  in  section  c.  This  valid 
schedule  can  be  improved  on  by  using  the  simulated  annealing  technique  described  in 
section  d. 

c.  Algorithm  for  Adjusting  Deadlines 

A  valid  schedule  is  a  schedule  that  satisfies  the  precedence  constraints  of  its 
tasks  but  allows  some  of  the  tasks  to  miss  its  deadlines.  Different  heuristics  can  be  used  to 
guide  the  search  process  to  a  plausible  path  that  minimizes  the  number  of  tasks  that  must 
miss  its  deadlines  and  in  the  mean  time  supports  team  work  by  scheduling  every  available 
task  as  soon  as  the  earliest  available  time  of  the  task  is  reached.  This  in  turn  minimizes  the 
time  a  designer  has  to  wait  for  a  task  to  be  assigned  to  him/her. 

This  algorithm  uses  almost  the  same  steps  as  in  the  previous  search  algorithm 
uses  with  two  main  differences.  The  first  difference  is  that;  there  is  one  ready_lists  for  each 
of  the  L  expertise  levels.  The  main  reason  for  having  the  di^erent  levels  of  ready  Jists  is  to 
guarantee  that  no  lower  task  is  assigned  to  a  higher  level  designer  while  there  is  a  task  of 
the  designer's  level  ready  to  be  assigned  (recall  the  requirement  that  the  expertise  level  of 
the  designer  must  be  at  least  the  same  as  that  of  the  assigned  task).  The  second  difference 
is  that  when  failing  the  strong  feasibility  check  for  extending  the  schedule  by  another  task, 
a  new  deadline  is  suggested  for  the  task  that  does  not  meet  its  deadline  (equal  to  its 
calculated  finish  time).  Upon  accepting  this  value  by  the  manager  the  schedule  is  extended 
to  the  next  level  and  so  on  until  a  valid  schedule  is  reached. 

The  Proposed  deadline-adjusting  scheduling  algorithm  works  as  follows; 

initialization_part: 

(1)  if  initial_schedule  =  empty 

(2)  then 

initialize  EAT  values  to  TO,  and  the  schedule  to  empty, 
perform  a  Depth  First  Search  on  the  dependency  graph  to; 

-  initialize  the  in_degree  for  each  node  (number  of  immediate  predecessors), 

-  propagate  deadlines,  and 

-  initialize  the  ESTs  (earliest  start  time)  of  the  steps  that  have  no  EST  to  TO. 
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Insert  each  pending  step  (its  in.degree  ^  0)  into  the  pending  list  according  to  its 
EST. 

(3)  else 

update  the  dependency_graph: 

•  Remove  the  assigned  steps  and  their  corresponding  arcs  from  the  dependency 
graph. 

-  Add  the  newly  arrived  steps  to  the  dependency  graph  (if  there  is  any)  check¬ 
ing  for  the  “acyclic”  property  of  the  graph  and  the  compatibility  of  the  newly 
added  steps’  priorities  with  that  of  their  successors  and  predecessors  and  warn 
the  manager  of  any  violation. 

Recalculate  the  in.degree  of  the  graph  nodes. 

Re-initialize  the  EAT  vector  (matrix)  to  the  finish  dme  of  the  step  assigned  to 
each  designer  and  to  t  for  those  free  designers. 

Insert  each  pending  step  (its  in.degree  =  0)  into  the  pending  list  ordered  by  its 
EST. 

end  if 

schedule_part: 

(4)  While  full.schedule  is  not  reached  loop 

(5)  For  all  the  steps  in  the  pending  list: 

if  EST  (S)  <*  min(EAT)  of  the  corresponding  designers  then 

insert  the  step  into  the  corresponding  ready.list  according  to  the  H 
(heuristic)  function  used  and  delete  it  from  the  pending  list 

end  if 

(6)  end  for 

(7)  For  ail  readyjists  from  higher Jevel  to  lower Jevel  loop 

(8)  While  readyjist  is  not  empty  loop 

(9)  if  not  FEASIBLE  to  extend  the  schedule  by  any  of  the  steps  in  the 
readyjist 

then  suggest  a  new  deadline  for  the  infeasible  step  assignment 
if  the  suggestion  is  not  accepted  then  exit,  end  if. 
end  if 

(10)  extend  the  schedule  by  the  step  S  that  has  min  H 

(11)  update  the  EAT  of  the  assigned  designer 

(12)  update  the  EST  of  the  immediate  successors  of  S 

( 1 3)  decrement  the  in_degree  of  the  immediate  successors  of  S 

(14)  if  the  in_degree  of  any  of  the  immediate  successors  of  S  =  0 
then 

insert  it  into  the  pending_list. 
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(18)  end  for 


end  if. 

delete  S  from  the  ready_Ust 

TO  =  min  (EAT)  of  the  designers  of  the  same  or  higher  expertise 
level  than  level(ready_list) 

for  all  the  steps  S  in  the  pending  list  such  that  expenise.level  (S)  » 
level  (ready_list): 
ifEST  (S)  <»T0 
then 

insert  S  into  the  ready.list  according  to  the  H  function  used 
and  delete  it  from  the  pending  list. 

end  if 
end  for 
end  while 

if  not  FEASIBLE  then  exit  end  if 
if  not  FEASIBLE  then  exit  end  if 


(19)  end  while 

This  algorithm  has  the  property  that  a  designer  will  never  be  left  idle  when  there 
is  a  ready  step  that  the  designer  is  qualified  to  do.  This  is  because  inserting  steps  into  ready 
list  and  their  assignment  to  designers  are  triggered  by  the  availability  of  designers  as  is  the 
case  in  statements,  10,  and  IS. 

As  an  example  to  illustrate  how  this  algorithm  works,  assume  we  have  the  same 
example  discussed  in  the  typical  scenario  in  chapter  3  as  represented  in  Table  10.  and  the 
corresponding  dependency  graph  in  Figure  26.  The  resources  in  this  example  are  three 
designers  dl,  d2,  d3  with  expertise  levels  H,  M,  L  respectively. 


TABLE  10.  THE  STEPS  TO  BE  SCHEDULED  AND  THEIR  ATTRIBUTES 


Step# 


est(S) 


tp(S) 


d(S) 


predecessor  (S) 


Successors  (S)  I  23 


r(S) 


6 

3 

18 

18 

1 

1 

5 

M 

M 

Its '!«'<■ 


Now  we  follow  the  algorithm  step  by  step  to  see  how  it  works: 

(1)  The  EAT  vector  is  initialized  to  zeros  EAT  =  (0, 0, 0)  for  dl,  d2,  d3  respectively. 


FIGURE  26.  The  dependency  graph 

(2)  Table  1 1  shows  the  new  deadlines  after  propagating  them  from  the  terminal  nodes 
all  the  way  up  to  the  corresponding  root  nodes  and  initializing  the  in.degree  and  the 
EST. 


TABLE  11.  THE  STEPS  ATTRIBUTES  AFTER  PROPAGATING  THE  DEADLINES. 


step# 

I 

2 

3 

4 

5 

6 

est(S) 

0 

0 

0 

0 

0 

tp(S) 

7 

6 

3 

6 

5 

4 

<i(S) 

11 

17 

18 

17 

22 

20 

predecessor  (S) 

1 

1 

2.4 

Successors  (S) 

5 

5 

r(S) 

M 

M 

M 

H 

H 

L 

in_degree  (S) 

DIHHI 

1 

1 

0 

2 

0 

.* 

'r 


it. 


* 

\ 


Using  H»d(S) 

(3)  The  steps  with  in_degree»  0  and  EST  ■  0  are  inserted  in  the  readyjist  Now  the 
readyjist »  (SI,  S4,  S6}  according  to  their  deadline  values. 

(4)  since  the  initial  partial  schedule  is  empty,  it  is  feasible  to  schedule  any  of  the  three 
steps  in  the  readyjist  without  missing  any  of  their  deadlines. 

(5)  The  partial  schedule  is  extended  by  SI  (inserting  the  steps  in  a  non-decreasing  order 
of  their  deadlines  into  the  readyjist  makes  no  need  to  apply  the  H  function,  since  the 
step  on  top  of  the  queue  has  the  min  deadline),  and  SI  is  removed  from  the  readyjist 
The  EAT  is  updated:  EAT  =  {0, 7, 0),  the  in_degree  of  steps  S2,  S3  is  decrement^  to  0. 
The  EST(S2)  and  EST  {S3)  are  set  to  7. 

^  (6)  Since  a  feasible  full  schedule  is  not  reached  yet  we  loop  back  to  step  3.  Table  12 

reflects  the  changes  after  first  iteration. 


1(X) 


(7.3)  S2,  S3  have  their  in_degree  =  0.  but  their  EST  >  min  (EAT).  Now  the  ready_list  = 
1S4, S6) 

(7.4)  The  partial  schedule  is  strongly  feasible  if  extended  by  any  of  the  steps  in  the 
ready_list 

(7.5)  The  partial  schedule  is  extended  by  S4,  it  is  removed  from  the  ready.list,  and  EAT 
is  updated  EAT  =  (6, 7, 0}.  the  in_degree  of  S5  is  decremented,  and  the  EST  (S5)  is  set 
to  6. 

TABLE  12.  THE  EFFECT  OF  THE  FIRST  ITERATION 


step# 


est(S) 


tp(S) 


d(S) 


predecessor  (S) 


Successors  (S)  I  23 


r(S) 


in.degiee  (S) 


(7.6)  Since  a  full  feasible  schedule  is  not  reached  yet  we  loop  back  to  step  3.  Table  13 
reflects  the  changes  after  second  iteration. 

TABLE  13.  THE  EFFECT  OF  THE  SECOND  ITERATION 


step# 


est(S) 


tp(S) 


d(S) 


predecessor  (S) 


Successors  (S)  23 


r(S) 


in_degree  (S) 


(8.3)  no  new  ready  steps  yet  The  readyjist  =  {S6} 

(8.4)  The  partial  schedule  is  strongly  feasible  if  extended  by  any  of  the  steps  in  the 
readyjist 

(8.5)  The  partial  schedule  is  extended  by  S6,  it  is  removed  from  the  ready_list,  and  EAT 
is  updated  EAT  =  {6, 7, 4). 

(8.6)  Since  a  full  feasible  schedule  is  not  reached  yet  we  loop  back  to  step  3.  Table  14 
reflects  the  changes  after  third  iteration. 


6 

3 

17 

18 

1 

1 

5 

M 

M 

0 

0 
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(9.3)  Now  the  readyjist  is  empty,  and  no  full  schedule  is  reached,  the  time  is  advanced 
to  maxfmin  (EAT),  min  (EST  (pending_list)))=  7,  both  S2  and  S3  are  ready  and 
inserted  into  the  ready  list  according  to  their  deadline  values.  Now  the  ready_list  =  { S2, 
S3) 

(9.4)  The  partial  schedule  is  strongly  feasible  if  extended  by  any  of  the  jtcps  in  the 
readyjist 

(9.5)  The  partial  schedule  is  extended  by  S2,  it  is  removed  from  the  ready_list,  and  EAT 
is  updated  EAT  =»  |6. 13. 4).  The  in_degree  of  S5  is  decremented  to  0,  and  its  EST  is 
updated  to  13. 

TABLE  14.  THE  EFFECT  OF  THE  THIRD  ITERATION 


step# 


est(S) 


tp(S) 


4(5) 


predecessor  (S) 


Successors  (S) 


r(S) 


in.degiee  (S) 


TABLE  15.  THE  EFFECT  OF  THE  FOURTH  ITERATION 


step# 


est(S) 


tp(S) 


d(S) 


predecessor  (S) 


Successors  (S) 


r(S) 


ui.degree  (S) 


(9.6)  Since  a  full  feasible  schedule  is  not  reached  yet  we  loop  back  to  step  3.  Table  16 
reflects  the  changes  after  fourth  iteration. 

(10.3)  no  new  steps  to  be  inserted  into  the  readyjist.  Now  the  readyjist  =  {S3 ) 

(10.4)  The  partial  schedule  is  strongly  feasible  if  extended  by  any  of  the  steps  in  the 
ready_list 
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TABLE  16.  THE  EFFECT  OF  THE  FIFTH  ITERATION 


(10.5)  The  partial  schedule  is  extended  by  S3,  it  is  removed  from  the  ready.list,  and 
EAT  is  updated  EAT  =  { 10.  13. 4). 

(10.6)  Since  a  full  feasible  schedule  is  not  reached  yet  we  loop  back  to  step  3.  Table  16 
reflects  the  changes  after  fifth  iteration. 

(11.3)  Again  the  ready  Jist  is  empty,  the  time  is  advanced  to  10  then  to  13  where  SS 
becomes  ready  and  inserted  into  the  readyjist  Now  the  ready  Jist »  (SS) 

(11.4)  The  partial  schedule  is  strongly  feasible  if  extended  by  any  of  the  steps  in  the 
readyjist 

(11.5)  The  partial  schedule  is  extended  by  S5.  it  is  removed  from  the  rcady.list,  and 
EAT  is  updated  EAT  ={  18,  13,  4). 

(11.6)  Since  a  full  feasible  schedule  is  reached  the  algorithm  stops.  The  resulting  sched¬ 
ule  is  shown  in  Table  17. 

TABLE  17.  THE  RESULTING  SCHEDULE 


step# 

designer 

fiiiisb_time 

SI 

d2 

TO 

T0i>7 

S2 

d2 

•n)tl3 

S3 

dl 

TDf7 

TIHIO 

S4 

dl 

TO 

T0<^ 

S5 

dl 

TOtl3 

T04-18 

S6 

<13 

TO 

■n)+4 

V.  EVALUATION  AND  VALIDATION 

A.  COMPLEXITY  ANALYSIS 

Both  of  the  two  algorithms  introduced  in  Chapter  IV.C.l.b  and  IV.C.l.c  have  a  total 
of  n  steps,  where  n  is  the  number  of  the  tasks  to  be  scheduled.  The  complexity  of  each  step 
is  determined  by  the  complexity  of  the  computation  done  to  determine  strong  feasibility 
and  the  complexity  of  H  function  evaluation.  The  strong  feasibility  calculation  is  linearly 
proportional  to  the  number  of  the  steps  in  the  ready  list  This  number  depends  on  the 
connectivity  of  the  dependency  graph  which  is  n  in  the  worst  case.  The  H  function 
computation  is  done  simply  by  inserting  the  ready  steps  into  the  ready  list(s)  in  order  of 
their  H  function  which  has  the  order  of  (log  n)  in  the  worst  case  if  we  use  a  heap  data 
structure  for  the  ready  lists. 

The  overall  worst  case  complexity  of  the  algorithm  is: 

n  +  (n  -  1)  +  (n  -  2)  + ..  +2  =  (9  (n^). 

The  backtracking  in  of  the  algorithm  in  Chapter  IV.C.  1  .b  can  be  limited  to  a  constant 
number  which  does  not  affect  the  complexity  analysis.  In  our  expermintal  results  we  found 
out  that  the  number  of  backtracking  is  at  most  proportional  to  n  with  a  small  constant  (0.75). 
It  is  also  worth  noting  that  the  number  of  steps  in  the  readyjist  is  linearly  proportional  to 
the  remaining  ready  unassigned  steps  which  is  always  less  than  or  equal  to  the  number  of 
the  remaining  unassigned  steps. 

B.  Simulation  Study 

The  main  goal  of  a  scheduling  algorithm  is  to  find  a  feasible  schedule  for  a  set  of  tasks, 
if  one  exists.  Clearly,  a  heuristic  scheduling  algorithm  is  not  guaranteed  to  reach  such  a 
schedule.  However,  one  heuristic  algorithm  is  favored  over  another,  if  we  have  a  number 
of  task  sets  that  known  to  have  feasible  schedules,  the  fust  is  able  to  find  feasible  schedules 
for  more  task  sets  than  the  second.  To  take  this  approach,  we  have  to  come  up  with  a 
number  of  task  sets,  each  of  which  is  known  to  have  a  feasible  schedule.  Unfortunately, 
only  an  exhaustive  algorithm  can  find  out  whether  an  arbitrary  task  set  can  be  feasibly 
scheduled. 
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Given  m  different  designers,  the  complexity  of  an  exhaustive  search  to  find  a  feasible 

schedule  for  n  tasks  in  the  worst  case  can  be  OCm"  *  n!).  This  is  why  we  take  the  approach 
taken  by  Ramamritham  et.  al.  [  Ref.  67]  which  is  using  a  task  generator  that  can  generate 
schedulable  task  sets  where  the  number  of  tasks  in  each  set  can  be  arbitrarily  large  without 
adding  much  complexity  on  the  task  generator.  Addidonally,  the  tasks  are  generated  to 
guarantee  the  total  utilization  of  the  available  designers.  These  task  sets  are  then  input  to 
the  scheduling  algorithm,  that  has  no  knowledge  that  these  sets  are  schedulable.  The 
parameters  used  to  generate  task  sets  are: 

1.  The  minimum  duration  of  a  task.  Min_D. 

2.  The  maximum  duration  of  a  task,  Max.D. 

3.  The  schedule  length,  L. 

The  task  set  generator  starts  with  an  empty  EAT  matrix,  it  then  generates  a  task  by 
selecting  one  of  the  n  designers  that  have  the  earliest  available  time  and  then  randomly 
chooses  the  task  duration  between  the  minimum  duration  and  the  maximum  duration.  The 
task  generator  then  increments  the  EAT  of  the  selected  designer  by  the  value  of  the  task 
duration.  The  task  generator  generates  tasks  until  the  remaining  unused  time  units  of  each 
designer,  up  to  the  schedule  length  L,  is  less  than  the  minimum  duration  of  a  task,  that 
means  no  more  tasks  can  be  generated  for  this  designer  within  the  given  schedule  length. 

The  deadline  for  each  task  is  chosen  randomly  between  the  task ‘s  shortest  completion 
time  Tjc  and  (1+F)  *  Tjc,  where  F  is  a  parameter  indicating  the  tighmess  of  the  deadlines, 
and  is  related  to  the  loading  factor  of  each  set  of  designers  of  the  same  expertise  level.  If  F 
is  0,  the  scheduler  must  be  able  to  find  the  same  schedule  as  that  found  by  the  task  generator 
in  order  to  reach  a  feasible  schedule.  As  the  value  of  F  is  increased  it  is  obvious  that  the 
scheduler  has  a  better  chance  to  find  a  feasible  schedule  for  the  task  set. 

1.  Simulation  Method 

In  our  simulation  study.  N  task  sets  are  generated,  where  each  set  is  known  to  be 
schedulable  according  to  the  task  set  generation  procedure  discussed  above.  Performance 
of  different  heuristics  arc  compared  according  to  how  many  of  the  N  feasible  task  sets  arc 
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found  schedulable  when  the  heuristics  are  used  [  Ref.  67],  We  use  the  same  metric  used  in 
[  Ref.  67]  which  is  defined  as: 


SR  =  ^ ,  where  s  is  the  number  of  schedulable  task  sets  found  by  the  heuristic 

algorithm,  and  N  is  the  total  number  of  task  sets. 

The  loading  factor  for  the  designers  is  different  according  to  their  expertise  level, 
we  assume  that  the  designers  are  of  three  different  expertise  levels  High,  medium  and  low, 
and  a  step  can  be  assigned  to  a  designer  that  has  at  least  the  same  expertise  level  as  that 
required  by  the  step.  This  assumption  make  the  loading  factor  varies  for  the  designers  in 
different  levels  as  defined  below. 

For  high  level  designers  we  define  the  loading  factor  as  follows: 

LFh  = 

iMax(di) -To)  xMh 


where  LFh  is  the  loading  factor  for  high  level  designers,  Tph  is  the  estimated  duration  for 
a  high  level  task.  To  is  the  initial  start  time  for  scheduling  the  tasks,  Mh  is  the  number  of 
available  high  level  designers  and  di  is  the  deadline  of  task  i. 

For  a  medium  level  designer  we  define  the  loading  factor  as  follows: 


LFm  = 


_ _ 

iMax{di)  -  To)  X  (Nm+Nh-NhxLFh) 


LFm  = 


_ _ 

{Max  {di)  -  To)  x  Mm  +  ( 1  -  LFh)  {Max  {di)  -  To)  x  Mh 


where  LFm  is  the  loading  factor  for  medium  level  designers,  Tpm  is  the  estimated  duration 
for  a  medium  level  task  and  Mm  is  the  number  of  available  medium  level  designers. 
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For  a  low  level  designer  we  define  the  loading  factor  as  follows: 


YtpI 

If  I - - 

{Max  {di)  -  To)  y.Nl+  (  1  -  LFm)  {Max  {di)  -  To)  X  (/Vm  +  /V/i  -  A//i  X  Lffi) 

Y/p! 

Lfl  =  - 5= - 

{Max  (dj)  -  To)  {N  -  Nh  {LFH  +  LFm  -  LFh  X  LFm)  -  LFm  X  Nm) 

where  LR  is  the  loading  factor  for  low  level  designers.  Tpl  is  the  estimated  duration  for  a 
low  level  task  and  Ml  is  the  number  of  available  low  level  designers. 

2.  Simulation  Results 

The  system,  in  our  experiment,  consists  of  three  designers,  one  of  each  expertise 
level  high,  ntedium  and  low.  Tasks  durations  are  randomly  chosen  between  Min.D  (2)  and 
Max_D  (20).  The  number  of  task  sets  generated  is  SO,  and  each  task  set  has  between  28  and 
31  tasks.  We  present  the  results  as  shown  in  Table  18,  and  in  plot  form  in  Figure  27  where 
the  success  ratio  SR  is  plotted  on  the  Y-axis  and  F  on  the  X-axis  (F  is  related  to  laxity). 
Simulation  parameter  is  F  to  measure  the  sensitivity  of  each  heuristic  algorithm  to  the 

change  in  laxities. 


TABLE  18.  Relation  between  Success  Ratio  (SR)  and  Laxity  (L) 


Laxity  (F) 

tm 

QH 

0.2 

OJ 

0.4 

im 

f 

IBI 

Heuristic  Search 

100 

100 

100 

100 

100 

100 

100 

100 

Min.D 

6 

14 

14 

40 

70 

72 

86 

100 

Min.s 

0 

ismn 

0 

8 

10 

10 

22 

Min.D  +  Min.s 

0 

0 

0 

0 

0 

0 

8 

16 

Min.L 

0 

0 

0 

0 

0 

0 

8 

10 

As  can  be  seen  from  Figure  27  the  greedy  heuristics  Min_D,  Min_S,  Min_D+ 
Min.S  and  Min.L  perform  poorly  due  to  the  dependency  relations  between  the  tasks.  We 
found  that  the  heuristic  search  algorithm  have  a  success  ratio  of  100%  even  when  the 
deadlines  are  very  tight  (F=0).  It  is  worth  noting  that  this  excellent  performance  by  the 
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Heuristic  Search 


heuristic  search  algonthm  is  obtained  with  unlimited  backtracking.  This  leads  us  to  study 
the  effect  of  limiting  the  backtracking. 

Instead  of  trying  different  backtracking  limits  and  studying  their  effects  on  the 
performance  of  the  algorithm,  we  do  it  the  other  way  around  by  counting  how  many  times 
the  algorithm  backtracks  to  get  a  feasible  schedule  given  the  different  task  sets.  The  results 
is  shown  in  Table  19  where  the  number  of  backtracking  is  represented  as  a  percentage  of 
the  total  number  of  tasks  in  a  task  set.  The  results  plotted  in  Figure  28  shows  that  the 
backtracking  limit  in  the  worst  case  (tightest  deadlines:  F=0)  is  approximatly  {).6  N,  where 
N  is  the  number  of  tasks  in  a  task  set,  and  this  limit  decreases  significantly  as  the  deadlines 
are  relaxed. 


FIGURE  27.  Relation  between  Success  Ratio  (SR)  and  Laxity  (L) 
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TABLE  19.  NUMBER  OF  BACKTRACKING  (AS  PERCENTAGE  OF  N)  AND  LAXITY  (L) 


Laxity  (F) 

tm 

m 

0.3 

mm 

f 

la 

backtracking  # 

.57 

.27 

.16 

.075 

.034 

.012 

0.0 

0.0 

C.  DEVELOPMENT  OF  TEST  CASES 

To  evaluate  the  ECS  system  and  its  proposed  functionality,  our  test  cases  are  designed 
to  show  that  the  ECS  realizes  the  two  main  claims;  1)  The  ECS  provides  automated  support 
for  changes  in  the  plan  during  the  execution  of  the  plan.  2)  It  provides  automatic  decision 
support  for  planning  and  team  coordination.  We  show  that  the  ECS  system  realizes  these 
two  main  issues  by  tailoring  the  test  cases  to  answer  a  set  of  questions  showing  the  fine 
details  pertaining  to  both  of  these  issues.  The  set  of  questions  are  as  follows: 


1.  Does  the  ECS  support  incremental  planning  of  new  evolution  steps  as  they  become 
available? 


2.  Does  the  ECS  respond  on  the  fly  to  changes  in  the  plan  (the  attributes  of  the  existing 
steps  and  the  changes  in  the  design  team  members)  reflecting  their  effects  on  the  cur¬ 
rent  plan  (schedule)? 

3.  Does  the  ECS  automatically  determine  change  consequences?  (calculates  the 
affected  modules  (components)  by  each  change  (step)  needed  for  propagating  the 
change  consequences  as  well  as  calculating  the  set  of  secondary  inputs  needed  to 
perform  the  required  change) 

4.  Does  the  ECS  automatically  guarantee  the  consistency  of  the  project  database?  (cre- 
at'.  a  substep  for  each  affected  module  by  the  proposed  top  step  and  include  it  in  the 
plan  for  implementing  the  change  and  restrict  the  commitment  of  the  top  step  by  the 
completion  of  all  its  substeps) 

5.  Does  the  ECS  support  automatic  VCCM?  (determines  and  saves  the  version  and 
variation  numbers  of  the  outputs  of  conunitted  steps  and  generates  a  new  system 
configuration  at  the  commitment  of  each  top  level  evolution  step?) 

6.  Does  the  ECS  support  parallel  multisystem  evolution? 

In  this  section  we  run  similar  scenarios  to  those  introduced  in  Chapter  Dl.F  as  our  test 
cases  for  the  evaluation  and  validation  of  the  ECS  system  performance.  During  the  test 
cases  we  indicate  the  answers  to  the  diff^erent  questions  presented  above. 

The  systems  we  are  evolving  are  called  “c3i_system”  and  “fishies”  where  simplified 
block  diagrams  of  their  decomposition  are  shown  in  Figure  29  and  Figure  30  to  make  it  easy 
to  follow  the  different  cases.  The  C3i_system  is  a  Command,  Control  and  Conununication 
information  system  developed  at  the  CAPS  lab.  The  fishies  system  is  fish  farm  control 
system  also  developed  in  the  CAPS  lab.  Notice  that  thick  arrows  indicate  both  “part.of  ’ 
and  “used_by”  relationships  and  the  thin  arrows  indicate  only  the  “used_by”  relationship 
among  the  system  components. 

The  set  of  initial  designers  arc:  “badr”  with  cxpertisc_levcl  “low”,  “brockett”  with 
expcrtise_lcvcl  “medium”  and  “dampier”  with  cxpcrtisc_lcvcl  “hii’h”. 

In  the  following  sub-sections  we  follow  a  typical  scenario  for  evolving  the  two 
systems  mentioned  above  indicating  in  each  subsection  the  ECS  system  features 
demonstrated. 
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c3i_sys(cm.l.l 
c3i_systein.spec.psdL  I .  I 


1.  Determining  Change  Consequences 

In  this  section  we  show  how  the  creation  of  a  step  with  a  given  primary  input 
automatically  generates  the  modules  affected  by  this  step  as  well  as  the  secondary  inputs 
needed  to  perform  this  step. 

1.  Starting  with  the  initial  configuration  of  “c3i_system  1:1"  (variation  number  1 
and  version  number  1),  we  create  three  steps:  first  step  with  primary  input 
‘‘c3i_system.sensor_interface.spec.psdr’,  second  step  with  primary  input 
‘‘c3i_system.spec.psdr’,  third  step  with  the  primary  input 
‘‘c3i_system.user_interface.manage_user_interface.imp.psdr’.  As  soon  as  the  manager 
clicks  the  apply  button  for  creating  a  step  the  ECS  assigns  a  unique  number  to  it  and 
generates  the  affected  modules  of  this  step. 

As  a  result  of  creating  furst  step,  the  ECS  assigns  it  a  unique  number,  1  in  this  case, 
and  generates  the  modules  affected  by  this  step  which  are  ‘‘c3i_system.imp.psdl  and 
c3i_systefn.sensor_interface.imp.psdl’’.  The  result  of  creating  the  second  step  is  assigning 
it  the  unique  number  2  as  its  stepjd  and  generating  the  affected  module  by  the  step  which 
is  ‘‘c3i_system.imp.psdr’.  Finally  the  result  of  creating  the  third  step  is  assigning  it  the 
unique  number  3  as  its  stepjd  and  generating  its  affected  modules  which  are  ‘‘none’’  in  this 
case  because  implementation  modules  do  not  affect  any  other  modules  and  the  ECS  also 
generates  its  secondary  input  which  is 

‘‘c3i_system.user_intcrface.managc_uscr_interface.spec.psdr’.  Notice  that  secondary 
inputs  generated  in  the  first  two  steps  were  none  because  the  primary  inputs  in  both  cases 
were  specification  modules  that  have  no  secondary  inputs  yet  since  we  did  not  have  the 
requirement  modules  in  our  database  yet  (planned  to  be  added  in  our  future  work). 

2.  Two  more  steps  are  created  starting  with  initial  version  of  “fishics  1:1”  (the  fish 
farm  control  system).  The  first  step  with  primary  input 
‘‘fishies.Control_water_Row.spec.psdr’  is  automatically  assigned  the  number  4  and  the 
two  modules  ‘‘fishies.imp.psdl  and  fishies.Control_watcr_Row.imp.psdl”  are  generated  as 
its  affected  modules.  The  second  step  with  primary  input  ‘‘fishies.Display_Status.imp.psdl” 
is  automatically  assigned  the  number  S  and  generates  no  affected  modules  and  the  ECS 
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generates  “fishies.Display_Status.imp.psdr'  as  its  secondary  input.  Images  of  the  ECS 
screens  for  the  details  of  the  created  steps  and  their  automatically  generated  attributes 
(affected  modules  and  secondary  inputs)  are  presented  in  Appendix  D  Figure  35,  Figure  36, 
Figure  37,  Figure  38,  and  Figure  39. 

Notice  that:  Creating  a  step  automatically  generates  the  affected  modules  by  the 
step  as  well  as  the  secondary  inputs  used  by  the  primary  input  of  the  step,  (answering 
questions). 

2.  Enforcing  Change  Consequences  for  Global  Consistency 

In  this  subsection  we  show  how  the  ECS,  after  the  manager  approval  of  a  step, 
will  automatically  create  a  substep  of  the  approved  step  for  each  affected  module  by  the 
step.  This  is  to  guarantee  that  all  the  change  consequences  are  considered  as  part  of  the 
original  change  and.  as  we  will  show  later,  that  completing  all  the  substeps  of  top  level  step 
is  enforced  as  a  condition  for  the  completion  of  the  top  step. 

The  manager  reviews  the  created  steps,  adds  the  deadline,  priority,  and  expertise 
level  for  each  step,  then  he  decides  to  approve  steps  1, 2  and  4.  The  result  of  approving  step 
I  is  creating  three  substeps  with  the  unique  numbers  6, 7.  and  8.  Step  6  has  the  primary 
input  “c3i_system.sensor_interface.spec.psdr*  which  is  the  primary  input  of  step  1 ,  that  is 
because  step  I  is  now  a  composite  step  and  will  only  be  used  for  controlling  and  enforcing 
the  completion  of  its  three  substeps  as  a  condition  forits  completion.  Step  7  has  the  primary 
inputs  “c3i_system.imp.psdr  and  its  secondary  inputs  are  automatically  generated  (the 
spec  component  of  c3i_system  and  the  spec  components  of  its  three  children  as  shown  in 
Figure  42  in  Appendix  D).  Step  8  has  the  primary  input 
“c3i_system.sensor_interface.imp.psdr’  and  it  has  the  spec  of  the  same  component  and  the 
specs  of  its  two  children;  as  it.s  secondary  inputs  as  shown  in  Figure  43  in  Appendix  D).  Both 
of  steps  7  and  8  automatically  have  step  6  as  its  predecessor,  since  the  results  of  step  6  are 
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the  basis  for  the  changes  required  by  them  (the  output  of  step  6  is  a  secondary  input  for  both 
steps  7  and  8). 


5 


FIGURE  30.  simplified  version  of  the  fish-farm  system  (fishies) 

Approving  step  2  automatically  creates  two  substeps  9  and  10  with  primary  inputs 
“c3Lsystem.spec.psdr’  and  “c3i_system.imp.psdr  respectively  where  step  9  precedes  step 
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10.  Approving  step  4  also  creates  three  substeps  11,12,  and  13  with  the  primary  inpi'ts  and 
secondary  '.nputs  shown  in  Figure  48,  Figure  49,  and  Figure  SO  in  Appendix  D.  Step  1 1 
precedes  both  of  steps  12  and  13  as  its  the  basis  for  their  changes. 

It  is  worth  noting  that  all  the  substeps  inherit  the  deadlines,  expertise.level  and 
the  priorities  of  their  top  level  steps  as  shown  in  the  corresponding  figures  of  the  screen 
images  of  the  details  of  the  steps  in  Appendix  D. 

Notice  that:  Approving  a  step  creates  a  substep  for  each  affected  module  by  the 
proposed  top  step.  The  newly  created  steps  are  atomic  and  inherits  the  status  “approved” 
of  their  top  steps  besides  their  attributes  (deadlines,  priorities,  and  expertise Jevel). 
(answer  for  question  4). 

3.  Incremental  Planning 

1.  The  manager  enters  an  estimated  duration  for  the  substep  from  6-13  using  the 
edit.step  command.  The  values  entered  are  6, 4, 5, 7, 3, 6,  S,  and  4  hours  respectively. 

2.  The  manager  starts  scheduling  the  steps  stardng  with  step  I  (related  to 
c3i_system  project).  Clicking  on  “schedule  step”  option  in  the  manager’s  menu  and 
entering  the  step  number  I ,  the  system  outputs  the  following  schedule  for  the  three  substeps 
of  step  1: 

STEP^ID  S_L!:VEL  D_HMIE  SThRT_TIM!:  riNISH_TIME 

6  SEDItni  bcockett  0  6 

8  HEDIUH  danpier  6  10 

7  HEOIUK  brockett  6  11 

Coxif  icmation  required  to  save  the  schedule  in  DDB.  hnsver(7/N)  :  y 

3.  As  soon  as  the  manager  confirms  the  output  of  the  scheduler,  the  ECS  saves  it 
in  the  design  database  replacing  the  hours  time  units  for  start_time  and  finish_timc  with  real 
dates  and  time  of  day,  as  captured  from  the  show.schedule  screen  below; 

6  11/06/93  08:32  11/06/93 14:32  brockett 

8  U/06/93 14:32  11/07/93 10:32  dampier 

7  11/06/93 14:32  11/07/93 11:32  brockett 
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The  ECS  also  sends  an  E_mail  message  to  brockett  informing  him  about  his 
assignment 

4.  Next,  the  manager  schedules  step  4  (related  to  the  fish  farm  project).  Clicking 
on  "schedule.step”  option  in  the  manager’s  menu  and  enters  the  step  number  4,  the  ECS 
outputs  the  following  updated  schedule. 


SZ3 

S_LEVn. 

0_NAME 

START_TIME 

PIMISH_TIME 

11 

LOW 

badr 

0 

6 

12 

LOW 

badr 

6 

11 

7 

MEDIOM 

danpier 

6 

11 

8 

MEDIUM 

brockett 

6 

10 

13 

LOW 

brockett 

10 

14 

||Coi\finiation  required  to  save  the  schedule  in  ODB.  Answer  (Y/N):  y 

Notice  that  step  6  does  not  show  in  the  output  of  the  scheduler  because  it  is 
already  assigned  to  a  designer  and  the  ECS  does  not  give  the  scheduler  the  flexibility  to 
change  the  assignment  for  step  6  to  save  the  work  done  on  that  step.  However  step  6  still 
appears  in  the  collective  schedule  saved  in  the  design  database  as  shown  below. 


6 

11/06/93  08:32 

11/06/93  14:32 

brockett 

8 

11/06/93  14:32 

11/07/93 10:32 

brockett 

7 

11/06/93  14:32 

11/07/93  11:32 

daxnpier 

U 

11/06/93  08:36 

11/06/93 14:36 

badr 

12 

11/06/93  14:36 

11/07/93  11:36 

badr 

13 

11/07/93  10:36 

11/07/93  14:36 

brockett 

One  more  feature  of  the  scheduler  is  assigning  the  ready  step  1 1  to  badr  right  away 
since  he  is  free  at  the  time  the  step  is  scheduled  for  him  and  sends  him  an  E.mail  informing 
him  about  his  assignment  as  shown  below. 

Notice  that  the  time  the  E.mail  message  is  sent  to  designer  badr  is  the  same  as  the 
start  time  of  his  assignment  in  the  schedule,  because  designer  badr  is  free  at  the  time  step  4 
is  scheduled. 

Before  scheduling  step  2  the  manager  enters  stepl  as  predecessor  of  step  2 
because  their  substeps  (step  7  and  step  10)  are  modifying  the  same  component.  This 
modification  automatically  makes  step  7  a  predecessor  of  step  10,  which  prevents  the  start 
of  step  10  until  the  completion  of  step  7. 
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From  badr  Sat  Nov  6  08:36:54  1993 
Return-Path:  <badr> 

Received:  from  9uns7-C8^)a. cs. nps. navy. nil  (sunsT, ce  nps. navy  mil) 
pe. navy,  mil  (4.  l/SllI-4. 1} 

id  M06828;  Sat,  6  Nov  93  08:36:54  PST 
Date:  Sat.  6  Nov  93  08:36:54  PST 
From:  badr  (ealah  badr) 

Meseage-Zd:  <931)061636.  AA06828&taurue. ce. npe  navy. mil> 

To:  badr 
Statue:  R 

You  have  been  assigned  the  step  no:  11 

&  n 


Using  the  same  command  as  in  4  above  the  manager  schedules  step  2.  The 
resulting  output  of  the  scheduler  is  shown  below  as  a  screen  image: 


STEP_ID 

S_LEVEL 

D_NRME 

STRRT^TIME 

FIN1SH_TIME 

9 

HIGH 

dampier 

0 

7 

12 

LOV 

badr 

6 

11 

8 

MEDIUM 

brocketb 

6 

10 

7 

MEDIUM 

dampier 

7 

12 

13 

LOV 

brockett 

10 

14 

10 

HIGH 

dampier 

12 

15 

jConfirmation  required  to  save 

the  schedule 

in  DDB  Answer  (Y/N) 

Notice  that  step  6  and  1 1  do  not  appear  in  the  output  of  the  scheduler  because  they 
are  already  assigned,  however  they  still  appear  in  the  schedule  in  the  DDB  as  shown  in  the 
screen  image  of  the  saved  schedule  below.  Also  an  e-mail  message  is  sent  to  designer 
dampier  informing  him  about  his  assignment 


6 

11/06/93  08:32 

11/06/93 14:32 

brockett 

8 

11/06/93  14:32 

11/07/93 10:32 

brocfcett 

7 

11/06/93  15:43 

11/07/93  12:45 

dampier 

11 

11/06/93  08:36 

11/06/93  14:36 

badr 

12 

11/06/93  14:36 

11/07/93  U:36 

badr 

13 

11/07/93  10:36 

11/07/93 14:36 

brockett 

9 

11/06/93  08:45 

11/06/93  15:45 

dampier 

10 

11/07/93  12:45 

11/07/93 15:45 

dampier 

Notice  also  that  step  10  is  scheduled  to  start  after  both  step  7  and  9  (its 
predecessors)  scheduled  finish  times. 
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As  a  conclusion  of  this  subsection,  we  have  shown  that:  I)  The  ECS  incrementally 
scheebiles  the  steps  as  soon  as  the  manager  decides  to  do  so.  2)  Preserves  the  precedence 
between  the  steps  and  meeting  their  deadlines  when  it  is  feasible  to  do  so.  3)  Ensuring  there 
is  no  the  case  that  a  designer  is  idle  and  there  is  a  ready  step  he  can  do  and  not  assigned 
to  him.  4)  automatically  informs  each  designer  of  his  due  assignment. 

4.  Changes  in  the  Plan 

Possible  changes  in  the  plan  include  the  changes  in  the  attributes  of  existing  active 
steps  such  as  deadlines,  priority,  precedence,  estimated  duration  or  even  adjusting  the 
affected  modules  and  secondary  input  as  well  as  suspending  or  abandoning  any  of  the  steps 
which  may  affect  the  plan  (schedule).  Another  possible  changes  are  the  changes  in  the 
designer  pool  by  adding,  deleting  or  changing  the  expertise  level  of  a  designer.  As  an 
example  of  these  changes  we  will  examine  changing  the  estimated  duration  of  some  of  the 
steps  either  by  an  early  commit  of  the  step  or  increasing  the  estimated  duration  of  another 
step.  We  will  also  examine  the  effects  of  suspending  a  step  and  deleting  a  designer. 

a.  Early  Commit  of  a  Step 

Now  designer  brockett  finishes  his  work  on  step  6  earlier  than  planned  (for 
the  sake  of  the  test  example)  and  commits  his  step.  His  commit  command  saves  his  changes 
to  the  design  database  creating  new  version  of  its  input  and  automatically  assigns  it  a 
version  and  variation  numbers  (variation  1  and  version  2  in  this  case).  This  also  triggers  the 
scheduling  mechanism  to  find  his  next  assignment  and  adjust  the  schedule  accordingly  as 
shown  in  the  screen  image  of  the  updated  schedule  below. 


8 

11^6/93  09:46 

11/06/93  13:46 

brockett 

7 

11/06/93 13:46 

11/07/93 10:46 

brockett 

11 

11/06/93  08:36 

ll/06<^  14:36 

badr 

12 

11/06/93  14:36 

11/07/93  U:36 

badr 

13 

U/06/93  13:46 

11/07/93  U:46 

daxnpicr 

dampier 

9 

11/06/93  08:45 

11/06/93  15:45 

10 

11/07/93  11:46 

11/07/93  14:46 

dampier 

As  shown  in  the  schedule  above  step  6  is  removed  from  the  current  schedule. 
Designer  brockett  gets  his  next  assignment  which  is  step  8.  The  stams  of  step  6  is  changed 
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to  “completed”,  and  its  finish  time  is  set  to  1 1/6/93  9:46  as  shown  in  the  screen  image  of 
the  details  of  step  6  in  Figure  SI  in  Appendix  D. 

Notice  that  the  availability  of  designer  brockett  earlier  affected  which 
designer  does  which  step  for  steps  that  are  scheduled  but  not  yet  assigned.  Now  step  7 
which  was  scheduled  before  for  dampier  is  scheduled  to  brockett  since  it  requires  his 
expertise  level  and  he  should  be  available  to  perform  this  step  before  its  deadline.  This  also 
changed  the  planned  assignment  for  dampier  from  step  7  and  10  to  steps  13  and  10.  As  a 
result  the  scheduled  finish  times  for  step  2  and  4  (and  their  substeps)  is  improved  (become 
earlier  than  before  committing  step  6). 

If  we  look  at  the  status  of  the  different  steps  in  the  system  after  the 
commitment  of  step  6  (using  the  command  show_steps  wi*h  option  “all”)  we  notice  that 
step  6  is  completed  while  steps  8,  1 1,  and  9  are  assigned  which  automatically  makes  the 
steps  1, 2,  and  4  have  the  assigned  status  (according  to  the  relations  between  top  steps  and 
their  substeps  defined  in  chapter  3  and  specified  in  Appendix  A.  The  rest  of  the  steps 
(except  step  3  and  S)  are  scheduled  with  estimated  start  time  as  indicated  in  the  schedule. 
Step  3  and  S  are  still  in  the  proposed  state. 


•tep.set  has  13  items. 

5,  Status:  proposed 

6,  Status:  completed 

7,  Status:  scheduled 

1,  Status:  assigned 

9,  Status:  assigned 

11,  Status:  assigned 

12,  Status:  scheduled 

3,  Status:  proposed 

4,  Status:  assigned 

8,  Status:  Msigned 

10,  Status:  scheduled 

2,  Status:  assigned 

13,  Status:  scheduled 
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b.  Increasing  Estimated  Duration  of  a  Step 

According  to  the  schedule  step  1 1  which  is  assigned  to  designer  badr  is  due 
to  complete  at  1 1/6/93  14:36.  but  he  is  asking  to  extend  the  estimated  duration  by  2  more 
hours.  Now  the  Manager  edits  the  estimated  duration  of  step  1 1  to  be  8  hours  instead  of  6 
using  the  edit  step  command  from  his  menu.  The  result  of  this  change  is  reflected 
automatically  on  the  schedule  as  shown  from  screen  image  of  the  new  schedule  below. 


8 

11/06/93  09:46 

11/  3/93  13:46 

bxoclsett 

7 

11/06/93  13:46 

11/07/93  10:46 

brockett 

U 

11/06/93  08:36 

11/06/93  16:36 

badr 

12 

11/06/93  16:36 

11/07/93  13:36 

badr 

13 

11/06/93  16:36 

11/07/93  12:36 

dampier 

9 

11/06/93  08:45 

11/06/93  15:45 

danq>ier 

10 

11/07/93  12:36 

11/07/93  15:36 

dampier 

Notice  that  the  finish  time  of  step  1 1  is  changed  to  be  16:36  instead  of  14:36 
in  the  previous  schedule,  and  accordingly  designer  badr’s  next  assignment  is  shifted  to  start 
at  16:36. 

c.  Suspending  a  Step 

Now  according  to  a  management  decision  step  4  has  to  be  suspended  because 
the  fish  farm  owner  has  a  budget  problem  and  cannot  afford  this  change  now  but  he  will  go 
with  the  other  change  proposed  by  step  S. 

The  manager  uses  the  suspend  step  command  to  suspend  step  4  which 
automatically  takes  its  substeps  (11,  12,  and  13)  out  of  the  schedule  and  their  status  is 
changed  back  to  approved.  The  screen  image  of  the  updated  schedule  after  suspending  step 
4  is  shown  below. 

8  11/06/93  09:46  11/06/93 13:46  biockett 

7  11/06/93 13:46  11/07/93 10:46  brockett 

9  11/06/93  08:45  11/06/93 15:45  dampier 

10  11/07/93 10:47  11/07/93 13:47  dampier 

because  of  suspending  step  1 1  (part  of  step  4),  an  E.mail  message  is  sent  to  designer  badr 
informing  him  that  his  step  is  suspended  as  shown  below. 
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ProM  ^adr  Sat  Nov  6  11;47:S2  1993 
Return-Path :  <badr  > 

Received:  from  sunsT-caps. ce. npe. navy. mil  (suns7. ce. nps. navy. mil) 
pe. navy. mil  (4. l/SMI-4. 1) 

id  AAOeOSO;  Sat.  6  Nov  93  11  47:46  PST 
Date:  Sat.  6  Nov  93  11:47:45  PST 
From:  badr  (ealah  badr) 

Heeeage-Id:  <9311061947. AR080509tauru3. ce.npe. navy. mil> 

To:  badr 
Status:  R 

Yoxir  current  assigned  step:  11  has  been  Suspended.  . . 

&D 


Now  the  manager  approves  step  S.  which  automatically  creates  one  substep 
with  the  unique  number  14.  The  manager  adds  an  estimated  duration  of  6  hours  to  step  14 
using  the  edit  step  command,  then  using  schedule  step  command  from  his  menu  schedules 
step  S  which  automatically  adds  its  atomic  substep  14  to  the  schedule  and  assigns  it  to 
designer  badr  who  is  idle  at  this  point.  The  screen  image  of  the  updated  schedule  is  shown 
below. 


8 

7 

9 

10 
14 


11/06/93  09:46 
11/06/93  13:46 
11/06/93  08:45 
11/07/93  10:47 
11/06/93 11:57 


11/06/93  13:46 
11/07/93 10:46 
11/06/93  15:45 
11/07/93  13:47 
11/07/93  09*.57 


brockett 

brockett 

daznpier 

dampier 

badr 


The  ECS  also  sends  an  E_mail  message  to  badr  informing  him  about  his  new 
assignment  as  shown  below. 

The  manager  also  approves  step  3  and  enters  duration  of  10  hours  to  its 
substep  (step  15),  then  he  schedules  step  3.  The  scheduler  finds  out  that  the  deadline  for 
step  IS  cannot  be  met.  It  suggests  the  calculated  finish  time  to  be  used  as  the  deadline  of 
this  step.  The  screen  image  of  the  scheduled  is  shown  below. 

Upon  the  acceptance  of  the  manager  to  the  system  suggestion  it  produces  a 
feasible  schedule  according  to  the  new  deadline  and  automatically  changes  the  deadline  for 
step  3  and  step  15  (the  substep  of  step  4)  to  the  new  value  as  shown  in  the  screen  images  of 
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7  MEDIUM  brockett  1  6 

15  LOV  danpier  3  13 

10  HIGH  dampier  13  16 

Confirmation  requirad  to  save  the  schedule  in  ODB.  Answer (Y/H): 

Step  3  and  step  15  in  Figure  55  and  Figure  55  in  Appendix  D.  The  screen  image  of  the 
updated  schedule  is  shown  below. 


8 

11/06/93  09:46 

11/06/93  13:46 

brockett 

7 

U/06/93  13:46 

U^07/93  10:46 

brockett 

9 

11/06/93  08:45 

ll/06<^3  15:45 

dampier 

10 

11/08/93  09:46 

11/08/93  12:46 

dampier 

14 

11/06/93 11:57 

U/07/93  09:57 

badr 

15 

11/06/93  15:46 

11/08/93  09:46 

dampier 

d.  Committing  a  Step 

Now  to  show  the  automated  VCCM  capabilities  of  the  ECS  let  us  commit  the 
substeps  of  step  I  then  step  1. 

First  let  designer  brockett  commits  step  8.  This  automatically  updates  the 
schedule  as  shown  below.  This  leads  to  assigning  brockett  strn  7  and  sending  him  an 
E_mail  message  informing  him  about  his  new  assignment 


122 


7 

11/06/93  13:46 

11/07/93  10:46 

brockett 

9 

11/06/93  08:45 

11/06/93  15:45 

dampier 

10 

11/08/93  09:46 

11/08/93  12:46 

dampier 

14 

11/06/93  11:57 

11/07/93  09:57 

badr 

IS 

11/06/93  15:46 

11/08/93  09:46 

dampier 

Now  for  the  sake  of  the  example  let  designer  brockett  commits  step  7.  This  is 
an  early  commit  which  automatically  updates  the  schedule  as  shown  below. 


9 

11/06/93  08:45 

11/06/93  15:45 

dampier 

10 

11/06/93  15:52 

11/07/93 10:52 

dampier 

14 

11/06/93  11:57 

11/07/93  09:57 

badr 

15 

11/06/93  13:52 

11/07/93  15:52 

brockett 

Notice  that  as  soon  as  designer  brockett  commits  step  7  the  system  assigns 
him  step  IS  which  was  planned  for  designer  dampier  before,  because  step  IS  is  ready  and 
designer  brockett  becomes  available  after  committing  step  7. 

Before  committing  step  1  let  us  have  a  look  at  the  versions  of  both  c3i_system 
and  fishies  prototypes  in  the  database  using  show  prototypes  corrunand  as  shown  below. 


fishief  Has  the  following  vexsions: 
iishiesU 

cSijfystem  Has  the  following  versions: 
cSij^temll 

a  «i  ee 


The  manager  commits  step  1  using  commit  step  command  from  his  menu 
when  all  the  verification  and  checking  for  the  substeps  are  done.  The  result  of  this 
command  is  creating  version  number  2  on  variation  number  1  of  the  c3i_sysem  as  shown 
below. 

fishies  Has  the  following  versions: 
fishiesll 

c3i_^tem  Has  the  following  versions: 

eSij^temll 

c3i_^teml2 


Now  if  we  look  at  the  available  steps  at  the  system  we  notice  that  step  1  and 
its  substeps  6, 7,  and  8  are  all  have  the  status  completed  when  we  use  the  show  steps  with 
the  option  completed  from  the  manager  menu  as  shown  below. 

step.set  has  15  items. 

6,  Status:  completed 

7,  Status:  completed 

1,  Status:  completed 

8,  Status:  completed 

The  screen  images  of  steps  6.  7.  8  and  1  after  they  have  been  completed 
showing  their  expertisejevel.  the  designer  assigned  to  each  step  the  start  and  finish  times 
as  well  as  the  rest  of  the  attributes  are  shown  in  Figure  SI.  Figure  S3,  Figure  SS,  and  Figure 
S4  in  Appendix  D. 

One  more  feature  of  the  ECS  is  related  to  the  default  base  version  to  which 
the  top  step  is  applied.  When  step  1,  2,  and  3  are  created  as  top  level  steps  they  had  the 
c3i_system  1 : 1  as  the  base  version  for  the  three  steps.  When  step  1  is  committed  producing 
c3i_system  1:2  the  default  base  version  for  both  steps  2  and  3  is  automatically  changed  to 
be  the  newly  created  version  c3i_system  1:2  as  shown  in  the  screen  images  of  step  2  and  3 
in  Figure  55  and  Figure  SS  in  Appendix  D. 

Another  important  feature  of  the  ECS  is  the  automatic  warning  to  both 
manager  and  designer  one  hour  before  a  step  is  due  to  commit  as  shown  in  the  E-mail 
message  below  received  by  the  manager. 

e.  Dropping  a  Designer 

Designer  dampier  commits  step  9,  and  the  manager  decides  to  schedule  step 
4  again.  Remember  that  when  step  4  was  suspended  before  its  sutus  changed  back  to 
approved.  The  updated  schedule  after  committing  step  9  is  shown  below. 


10 

11/06/93  15:52 

11/07/93  10:52 

dampier 

14 

11/06/93  11:57 

11/07/93  09:57 

badr 

15 

11/06/93  13:52 

11/07/93  15:52 

bzockett 
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FroB  badr  Sat  Nov  £  14:26:18  1993 
Return-Path:  <badr> 

Received;  from  eunsT-cape.  ce.npe.  navy. nil  (ewe?,  cs.npe.  navy,  nil) 
pe. navy. mil  (4. 1/SMI -4. 1) 

id  Ah08946;  Sat.  6  Nov  93  14:26:18  PST 
Date:  Sat.  6  Nov  93  14:26:18  PST 
From;  badr  (ealah  badr) 

Message-Zd:  <9311062226. AAQ89469taurua. cs. nps. navy. mil> 

To;  badr 
Status:  R 

RTIENTION  REQUIRED  Step:  9  should  commit  vithin  an  hour.  .  . 


The  manager  uses  schedule  step  command  for  step  4  then  the  ECS  produces 
the  updated  schedule  below. 


10 

U/06/93  15:52 

11/07/93  10:52 

dampier 

14 

11/06/93  11:57 

11/07/93  09-.57 

badr 

15 

13:52 

11/07/93  15:52 

brockett 

U 

11/07/93  09:57 

11/08/93  09:57 

badr 

13 

U/08/93  09:57 

11/08/93 13:57 

dampier 

12 

11/08/93  09:57 

11/08/93  14:57 

badr 

Now  the  manager  decided  to  send  designer  badr  to  one  of  the  sites,  so  he  must 
delete  him  from  the  schedule.  The  manager  uses  drop  designer  option  from  the  edit_team 
sub-menu.  After  the  system  asks  for  the  manager’s  confirmation,  it  suggests  deadline 
changes  for  both  steps  13  and  12  as  shown  below. 

When  the  suggested  deadline  changes  is  accepted  by  the  manager,  the  ECS 
produces  the  following  updated  schedule. 


10 

11/06/93  15:52 

11/07/93 10’^2 

dampier 

14 

11/07/93 10:59 

11/08/93  08:59 

dampier 

15 

11/06/93  13:52 

11/07/93  15-.52 

brockett 

11 

11/07/93  15:59 

11/08/93  15:59 

brockett 

13 

11/08/93  15:59 

U/09/83  U:59 

dampier 

12 

11/08/93  15:59 

U/09/93 12:59 

brockett 

Notice  that,  the  assigned  and  the  planned  steps  for  designer  badr  are 
rescheduled  to  both  designers  brockett  and  dampier. 


NOTICE:  The  Oeeigner  juet  deleted  vae  busy 
RESCHEOOLINO  his/her  taaks. 
in-feasible  schedule;  step  #  13 
suggested  deadline  should  be  >-  20 
Would  you  like  to  change  it?  Answer  (y/n)y 

Enter  the  new  Deadline  20 
in-feasible  schedule;  step  #  12 
suggested  deadline  should  be  >-  21 
Would  you  like  to  change  it?  Answer  (y/n)y 


Enter  the 
STEP^ID 

new  Deadline  21 
S^LEVEL  D.MAIE 

START_TI11E 

PINISH_TIBE 

U 

LOW 

daig>ier 

3 

9 

11 

LOW 

brockett 

8 

16 

12 

LOW 

brockett 

16 

21 

13 

LOW 

danpier 

16 

20 

D.  ANALYSIS  OF  RESULTS 

1.  The  ECS  automatically  identifies  the  affected  components  by  the  proposed  changes 
(the  primary  inputs  of  the  proposed  changes)  which  is  very  important  for  software 
consistency. 

2.  The  ECS  creates  a  substep  for  each  aff«:ted  module  of  each  approved  step  as  a  way 
to  enforce  the  propagation  of  the  change  effects  to  guarantee  software  consistency. 

3.  The  ECS  gives  the  manager  the  edit  capability  to  override  the  automated  decisions 
which  is  always  needed  to  give  the  managers  a  sense  of  control  over  their  systems, 
and  also  to  add  the  necessary  information  for  the  automated  function  to  be  per¬ 
formed  properly 

4.  The  ECS  supports  incremental  planning  and  rescheduling  of  tasks  according  to  the 
expertise  level  requLod  by  each  task,  available  designers,  deadlines  constraints,  pre¬ 
cedence  and  priority  constrains  that  is  needed  for  medium  to  large  software  system 
that  experience  large  number  of  changes  that  involves  many  designers. 

5.  The  system  also  has  an  automated  transparent  version  control  and  configuration 
management  system  that  keeps  track  of  the  evolution  history  of  the  system  through 
tracking  the  software  component  versions  and  which  component  belongs  to  which 
configuration 

6.  The  ECS  keeps  the  information  among  the  three  components  of  its  state  model  con¬ 
sistent  all  the  times  to  support  cooperative  work  for  multi-user,  multiple  projects 
organizations. 


VI.  CONCLUSIONS 


A.  SUMMARY 

In  this  dissertation,  we  have  presented  the  Evolution  Control  System  (ECS)  as  an 
integrated  system  for  software  evolution.  We  integrate  a  transparent  version  control  and 
configuration  management  mechanism  for  evolving  software  systems  together  with  an 
assignment  and  scheduling  system  to  enforce  cooperation  and  coordination  between 
designers  working  concurrently  on  the  same  or  different  systems.  This  integrated  system  is 
necessarily  dynamic  to  cope  with  the  special  nature  of  the  software  evolution  problem 
where  the  steps  (changes)  to  be  coordinated,  scheduled  and  carried  out  are  only  partially 
known.  Time  required,  the  set  of  sub<tasks  for  each  step,  and  the  input/output  constraints 
between  steps  are  ail  uncertain,  and  subject  to  change  as  evolution  steps  are  carried  out  The 
ECS  introduces  the  following  features: 

1.  Automated  support  for  changes  in  plan  during  the  execution  of  the  plan. 

2.  Automatic  decision  support  for  planning  and  team  coordination  based  on  design 
dependencies  captured  in  the  configuration  model. 

3.  Enhanced  graph  model  for  software  evolution  implemented  as  the  main  part  of  the 
state  model  of  the  system. 

4.  The  development  and  implementation  of  an  automated  version  control  and  configu¬ 
ration  management  mechanism  that  automatically  keeps  track  of  the  software  com¬ 
ponent  versions  and  which  component  belongs  to  which  configuration. 

5.  The  development  and  implementation  of  a  mechanism  for  detecting  change  conse¬ 
quences  (determining  the  components  affected  by  a  change)  to  maintain  the  global 
consistency  of  the  design  database  and  provide  serializability  of  updates. 

6.  The  development  and  implementation  of  a  dynamic  heuristic  scheduling  algorithm 
that  finds  a  feasible  schedule  that:  meets  the  deadline  and  precedence  constraints  of 
all  the  active  steps,  or  suggest  new  deadlines  for  the  lowest  priority  deadlines  until  a 
feasible  schedule  that  meets  the  deadlines  of  the  higher  priority  steps  is  reached.  In 
addition,  the  scheduling  mechanism  supports  increment^  replanning  as  additional 
.lew  steps  are  created  or  the  attributes  of  the  existing  steps  are  changed. 

7.  The  above  features  are  integrated  in  such  a  way  that  it  is  possible  to  use  the  serializa¬ 
tion  of  tasks  according  to  their  precedence  constraints  as  a  method  for  concurrency 
control  as  explained  in  detail  in  Chapter  IV.A.2. 

We  have  found  that  providing  automated  support  for  the  following  aspects  of  software 
evolution  is  practical  and  feasible. 
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1.  Changes  in  the  plan  during  the  execution  of  the  plan, 

2.  Planning  and  team  coordination  based  on  design  dependencies, 

3.  Detecting  change  consequences, 

4.  Non-serialized  parallel  elaborations,  and 

5.  Automated  version  control  and  configuration  management 

B.  IMPORTANCE  OF  RESEARCH  RESULTS 

The  importance  of  this  research  is  that  it  provides  managers  of  the  medium  to  large 
software  projects  with  the  automated  help  they  need  to  make  informed  and  intelligent 
decisions  in  the  management  of  software  systems  under  development/evolution.  This  is 
especially  important  in  environments  where  the  number  of  changes  is  very  large,  difficult 
to  follow  up  manually,  hard  to  coordinate  and  have  their  consequences  detected  and 
propagated,  which  in  turn  threatens  the  consistency  of  the  software. 

Automated  help  for  detecting  change  consequences  and  coordinating  changes 
according  to  the  relations  and  constraints  among  different  changes  not  only  guarantees 
system  consistency,  but  also  guarantees  full  utilization  of  the  human  resources  assigned  to 
perform  coordinated  changes  and  avoids  rollbacks. 

Keeping  a  complete  record  of  the  software’s  evolution  history  via  the  developed 
configuration  graph  provides  a  rich  history  trail  for  future  management  reference. 

Automatically  tracking  of  software  component  versions  and  component  configuration 
dependencies  in  a  way  that  is  transparent  to  users  relieves  both  managers  and  designers 
from  the  burden  of  manual  book-keeping  of  the  evolution  history,  which  is  a  very  hard,  if 
not  impossible,  task  in  medium  to  large  systems. 

C.  PROPOSED  EXTENSIONS 

The  main  proposed  extension  to  this  woiir  is  to  develop  and  integrate  a  requirement 
dependencies  mechanism  which  will  propagate  changes  not  only  between  the  specification 
and  implementation  components,  but  also  include  requirements  documents  on-line  where 
any  change  to  a  software  system’s  requirements  automatically  triggers  proposed  changes 
to  corresponding  specification  modules  and  subsequently,  the  implementation  modules. 

Another  plausible  refinement  is  to  limit  the  responsibilities  of  each  designer  for  a  set 
of  projects  which  constrains  the  ECS  step  assignii^nts.  Moreover  make  the  scheduler  take 
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into  consideration  other  demands  on  designers  time  such  as  meetings,  demos  etc.  Also 
include  the  option  of  limiting  managers  responsibilities  to  a  single  project. 

Other  extension  is  to  integrate  a  change-merging  mechanism  which  will  allow  the 
manager  to  autonudcally  combine  results  of  several  completed  steps  that  were  explored  in 
parallel.  This  aspect  is  currently  being  explored  [22]  [23]. 

Another  possible  extension  is  the  integration  of  policies  for  automatic  quality  check 
procedures  before  the  commitment  of  steps.  A  minimum  step  in  this  direction  is  to  ensure 
that  the  software  can  be  compiled  without  errors  before  it  can  be  committed  to  the  design 
database. 

As  for  the  implementation  of  the  ECS  system  the  following  improvements  are 
required: 

1.  Integrating  the  menu  driven  user  interface  commands  to  the  existing  Tae  user  inter¬ 
face. 

2.  Find  a  way  for  direct  interface  between  Ada  and  Ontos  DB  to  save  the  interface  time 
between  Ada  to  C-h-  then  to  Ontos  which  will  significandy  enhance  the  ECS  perfor- 


VII.  APPENDICES 


A.  Formal  Specifications 

1.  State  Model  and  related  concepts 
DEFINITION  ECS.state.model 
INHERIT  configuration_graph 
INHERIT  designer 
INHERIT  schedule 
STATE  ( graph:  configuration_graph, 
schedule:  schedule.type, 

••  The  schedule  also  is  used  for  optemizing  the  operations  of  the 
~  scheduling  algorithm. 

primaiyjnput:  map  (step,  set  (component_reference) ), 

secondary.inpuc  map  (step,  set  (component.reference)}, 

affected.modules:  map  {step,  set  (component.reference) }, 

deadline:  map  (step.time), 

estimatcd_duration:  map  (step,  natural }. 

precedence:  map  (step,  set  (step) ), 

priority:  map  (step,  integer}, 

status:  map  (step,  step.sutus), 

step_expertise_levcl:  map  (step.expjevel), 

designer_pool:  set  (designer}) 

INVARIANT 

feasible.schedule  (schedule)  I  manager_notified  (schedule), 

-  either  a  feasible  schedule  is  reached  or  manager  is  notified  of  suggestion 

-  to  get  a  feasible  one. 
known.designers  (schedule). 

~  every  designer  in  the  schedule  must  be  in  the  designer_pool 
acdve.steps  (schedule). 
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~  each  step  in  the  schedule  must  be  in  the  configuration  graph,  must  be  atomic 
~  and  its  status  must  be  either  scheduled  or  assigned, 

-  and  the  schedule  must  include  all  such  steps, 
single.assignment  (schedule) 

-  no  more  than  one  step  is  assigned  to  the  same  designer  at  the  same  time 

INITIALLY  graph  *  empty  .graph, 
designer_pool  ac  ( ). 
schedule  3  ( ) 

CONCEPT  component.reference;  type 

WHERE  Subtype  (specific.component.referencc,  component.reference) 

CONCEPT  object.id  (c:  component.refcrence)  VALUE  (obj_id:  string) 

CONCEPT  variadonjd  (c:  component.reference)  VALUE  (var.id:  natural) 
CONCEPT  version.id  (c;  specific_component_reference)  VALUE  (v_id:  natural) 
CONCEPT  topjevel  (c:  specific.component.reference)  VALUE  (b:  boolean) 
WHERE  b  <=>  -EXISTS(cl:specific_component_reference ::  c  part.of  cl) 

-  prototypes  are  represented  as  topjevel  components 

CONCEPT  step.status:  type 

WHERE  step.status  =  enumeration  (proposed,  approved,  scheduled,  assigned, 
abandoned,  completed,  all) 

-  all  is  used  to  indicate  all  the  steps  of  a  certain  prototype  disregarding  their  status 
CONCEPT  expjevel::  type 

WHERE  expjevel »  enumeration  (low,  medium,  high,  none) 

-  none  is  used  as  a  default  value  for  the  expertise  Jevel  of  a  step  and  treated  as 

-  low  to  distinguish  between  the  values  entered  by  the  manager  and  the  default 

-  values. 
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CONCEPT  feasible.schedule  (s:  schcdule_type)  VALUE  (b:  boolean) 

WHERE  b  <«>  known.designers  (s)  &  single  assignment  (s)  &  active.steps  (s) 
&  predecessors.finished  (s)&  on.time  (s.  deadline)  &  sufficient_expertise  (s) 
CONCEPT  known.designers  (s:  schedule.type)  VALUE  (b:  boolean) 

WHERE  b  <»>  ALL  (d:  designer  SUCH  THAT  d  IN  s::  d  IN  designer_pooi) 

-  every  designer  in  the  schedule  must  be  in  the  designer_pool 

CONCEPT  single.assignment  (schedule:  schedule_type)  VALUE  (b:  boolean) 
WHERE  b  <=>  ALL  (si,  s2;  step::  si  IN  schedule  &  s2  IN  schedule  & 
schedule  (sl).designer  «  schedule  (s2).designer  & 
schedule  (sl).scheduled_flnish_time  >  schedule(s2).scheduled_start_time 
>  schedule(sl).scheduled_start_dme  s>  sl»  s2) 

-  no  more  than  one  step  is  assigned  to  the  same  designer  at  the  same  time 

CONCEPT  active_steps  (s:  schedule_typc)  VALUE  (b:  boolean) 

WHERE  b  <=>  ALL  (st:  step::  st  IN  s  <=>  stcp_in_graph  (st,  graph)  &  atomic  (st) 
&  status  (st)  IN  (scheduled,  assigned}) 

-  each  step  in  the  schedule  must  be  in  the  configuration  graph,  must  be  atomic, 

-  and  its  status  either  scheduled  or  assigned,  and  the  schedule  must  include  all 
••  such  steps 

CONCEPT  atomic  (st:  step)  VALUE  (b:  boolean) 

WHERE  b  <=>  -  EXISTS  (stl:  step ::  stl  part_of  st) 

-  A  step  is  atomic  if  it  has  no  substeps. 

CONCEPT  pTedecessors_finished  (schedule:  schedule.type) 

VALUE  (b:  boolean) 

WHERE  b  <=>  ALL  (stl,  st2:  step  SUCH  THAT  stl  IN  schedule  & 
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st2  IN  schedule  &  precedes  (stl,  st2,  dep_£raph) :: 

schedule(stl).scheduled_finish_tiiij:  <»  schedule(st2).scheduled_start_tifne) 

CONCEPT  on_tiine  (schedule:  schedule_type,  d:  map  (step.time)) 

VALUE  (b:  boolean) 

WHERE  b  <->  ALL  (st:  step  SUCH  THAT  st  IN  schedule::  schedule 
(st).scheduled_finish_dme  <»  d  (st)) 

CONCEPT  sufficient_expertise  (schedule:  schedule_type)  VALUE  (b:  boolean) 
WHERE  b  <=>  ALL  (st:  step  SUCH  THAT  st  IN  schedule:: 
step_expertise_level  (st)  <=»  designer_expertise_levcl  (schedule  (st).designer)) 

-  a  designer  can  be  assigned  to  a  step  only  if  his  experdsejevel  is  at  least 

-  that  of  the  assigned  step 

CONCEPT  unique_step_id  (s:  step)  VALUE  (b:  boolean) 

WHERE  b  <=>  ALL  (si:  step::  step_id  (si)  =  stepjd  (s)  *>  sl=  s) 

-  stepjd  is  unique  for  all  steps. 

END 

a.  ConfigMiration  graph 
DEFINITION  configuration_graph 
INHERIT  component.node 
INHERIT  step_node 

MODEL  (component_nodes:  set  {version},  step_nodes:  set  (step), 

part_of_edges,  used_by_edges.  Ledges,  0_edges:  set  {pair}) 
INVARIANT 

ALL  (g:  configuration_graph,  e:  pair  SUCH  THAT  e  IN  g.part_oLedgcs:: 
[(e.start  IN  g.component_nodes  &  e.end  IN  g.component_nodes)  I 
(e.start  IN  g.stcp_nodcs  &  e.end  IN  g.step_nodes)] 
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I  e  IN  g.uscd_by_cdgcs::  e.start  IN  g.componem_nodes  &  c.cnd  IN 
g.coinponent_nodes  I  e  IN  g.I_cdges::  e.stait  IN  g.component.nodes  &  e.cnd  IN 
g.step.nodes 

I  e  IN  g.O_cdges::  e.start  IN  g.stcp_nodcs  &  c.end  IN  g.component_nodes) 


CONCEPT  is_componcnt_nodc  (x;  version,  g;  configuration_graph) 
VALUE  (b:  boolean) 

WHERE  b  <=>  X  IN  g.component.nodes 


CONCEPT  component_in_graph  (o:  component_reference,  g:  conriguradon_graph) 
VALUE  (b:  boolean) 

WHERE  b  <»>  SOME  (c:  version  SUCH  THAT  is.component.node  (c,  g):; 
objectjd  (c)  =  objectjd(o)) 

CONCEPT  step_in_graph  (s:  step,  g:  configuration_graph)  VALUE  (b:  boolean) 
WHERE  b  <«>  s  IN  g.step_nodes 

CONCEPT  empty_graph  VALUE  (g;  configuration_graph) 

WHERE  g.nodes  »  ( ),  g.edges  »  { ) 

CONCEPT  add.step^node  (s:  step,  gl:  conflguration_graph) 

~  Add  a  step  node. 

VALUE  (g2:  configuration_graph) 

WHERE  g2.step_nodes  =  gl.step_nodcs  U  (s),  g2.coinponent_nodes  = 
gl.component.nodes,  g2.edges  =  g  Ledges 

CONCEPT  add_component_node  (c:  version,  gl:  configuration_graph) 

-  Add  a  component  node. 
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VALUE  (g2:  conriguration_graph) 

WHERE  g2.componcni_nodes  *  gl.componcm_nodcs  U  {c},  g2.step_nodcs  = 
gl.stq)_nodcs,  g2.edges  =  g  Ledges 

CONCEPT  add_input_edge  (c:  version,  s:  step,  gl:  configuration_graph) 

--  Add  an  input  edge. 

VALUE  (g2:  configuration_graph) 

WHERE  g2.component_nodes  =  gLcomponent_nodes  U  (c).  g2.step_nodes  = 
gl.step.nodes  U  (s) 

g2.I_edgcs  «  gl. Ledges  U  {[start::  c,  end::  sj).  g2.0_edges  =  gl.0_edges. 
g2.part_of_edges  =  gl.part_of_edges.  g2.used_by_edgcs  =  gl.used_by_edges 

CONCEPT add.output.edge  (s:  step, c:  version,  gl:  configuration_graph) 

-  Add  an  input  edge. 

VALUE  (g2:  configuration_graph) 

WHERE  g2.coniponent_nodes  =  gl.component_nodes  U  [c), 
g2.step_nodes  =  gl.stcp_nodcs  U  {s} 

g2.I_edges  «  gl.Ledges,  g2.0_edges  » gl.O_edges U  {[start::  s, end::  cl), 
g2.part.of_edges  »  gl.pan_of_edges,  g2.used_by_edges  =  gi.uscd_by_edges 

CONCEPT  remove_input_edge  (c:  component,  s:  step,  gl:  configuration_graph) 

-  Remove  an  input  edge. 

VALUE  (g2;  configuration_graph) 

WHERE  g2.nodes  =  gl. nodes, 

g2.I_edges  =  gl. Ledges  -  {[start::  c,  end::  sU,  g2.0_edges  =  gl.O_edges, 
g2.part_of_cdges  =  gl.part^oLcdges,  g2.used_by_edges  =  gl.used_by_edges 

CONCEPT  rcmove_input_cdgcs  (s,  gl)  VALUE  (g2:  configuration_graph),  WHERE 
g2.nodes  »  gl. nodes. 
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g2.I_cdgcs  »  gl. Ledges  -  {ALL  (e:  Ledge  SUCH  THAT  end  (e)=  s)}, 
g2.0 .edges  =  gLO_edges.  g2.part_oLcdgcs  =  gl.part_of_cdges, 
g2.used_by_edges  =  gl.used_by_edgcs 

CONCEPT  configuration_graph_node:  type 
WHERE  Subtype  (version.  configuration_graph_nodc), 

Subt;T)c  (step,  configuration.^raph_node). 

ALL  (n;  configuration.graph_nodc  ::  n  IN  version  I  n  IN  step) 

-  configuration  graph  nodes  are  either  steps  or  versions. 

CONCEPT  pair:  type 

WHERE  pair  =  tuple  {start,  end::  configuration_graph_node  | 

CONCEPT  version:  specific_component_reference 
END 

DEFINITION  step^node  --  Concepts  for  describing  stcp_nodc 

CONCEPT  step:  type 

CONCEPT  step_id  (s:  step)  VALUE  (sjd:  natural) 

CONCEPT  top_level(s:  step)  VALUE  (b:  boolean) 

WHERE  b  <=>  ~EXISTS(sl:  step::  s  part_of  si) 

END 

DEFINITION  dependency^graph  -  Concepts  for  describing 

dependency_graph 

dcp_grapha  f(dep_nodcs,  dcp_edges) 

CHOOSE  (dep_nodes,  dep.edges  SUCH  THAT 

ALL(n::  n  e  dep_nodes  <=>  n  IN  graph.step. nodes  & 

status(step(n))  IN  (scheduled,  assigned)  &  atomic  (step(n)))  & 
ALL(c::  e  e  dep_edges  <=>  e.start,  c.end  IN  dep_nodes )) 

END 
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b.  DesignerJPool 


DEFINITION  designer  --  Concepts  for  describing  designer.pool 

CONCEPT  designer:  type 
CONCEPT  name  (d:  designer)  VALUE  (n:  string) 

CONCEPT  designer_expertise_level  (d:  designer)  VALUE  (e:  exp_level) 
CONCEPT  status  (d:  designer)  VALUE  (s:  enumeration  (busy,  free}) 

END 


e.  Schedule 

DEFINITION  schedule  --  Concepts  for  describing  the  schedule 

CONCEPT  schcduic.typc;  type 

WHERE  schedule.type  »  map  (s:  step,  tuple  {d::  designer,  schcduled_stan_timc. 
scheduled.finish.time:  time}) 

CONCEPT  update.schedule  (old_schcdule:  schcdule.type,  s:  step  SUCH  THAT 
status  (s)  =  approved) 

VALUE  (new_schcdule:  schedule_type) 

~  recalculate  schedule  due  to  scheduling  a  new  step 

WHERE  ALL  (si:  step  SUCH  THAT  si  part.of  s  &  atomic  (si):: 

si  IN  new_schedule)  &  ALL  (si:  step::  si  IN  old_schedule  =>  si  IN  new_schedulc) 

CONCEPT  update.schedule  (old_schedule:  schedule_type,  s:  step  SUCH  THAT 
status  (s)  IN  (abandoned,  completed}) 

VALUE  (new_schedule:  schedulc_type) 

"  recalculate  schedule  due  to  abandoning  a  step 

WHERE  ALL  (si:  step  SUCH  THAT  si  part_of  s  &  atomic  (si):: 

-  (sl  IN  new_schcdulc)  &  EXISTS  (s2  IN  ncw_schedule  SUCH  THAT 
new_schcdulc  (s2).designer = old_schedule  (s  1  ).designer  &  status  (s2)  =  assigned))  & 
ALL  (s2:  step::  s2  IN  old_schcdule  <=>  s2  IN  new_schedule  I  s2  part_of  s) 
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CONCEPT  updatc_schcdulc  (old.schcdulc:  schcdulc.typc,  d:  designer  SUCH  THAT 

-  (d  IN  old.schedule)) 

VALUE  (new_schedule:  schedule_type) 

-  recalculate  schedule  after  adding  a  new  designer 

WHERE  (d  IN  new_schedule  &  ALL  (si:  step::  si  IN  new_schedule  <=>  si  IN 
old.schedule)) 

CONCEPT  update_schedule  (old_schedule:  schedule_type,  d:  designer  SUCH  THAT 

d  IN  old_schcdule) 

VALUE  (new_schedule:  schedule_type) 

-  recalculate  schedule  after  dropping  a  designer 

WHERE  (-(d  IN  new.schedule)  &  ALL  (si:  step::  si  IN  new.schedule  <=> 
si  IN  old.schedule)) 

CONCEPT  schedule_changes  (old.schedule,  new_schedulc:  schedule.type) 

VALUE  (ch:  schedule.type) 

WHERE  ALL  (si:  step::  si  IN  ch  <=>  (si  IN  old_schedule  &  -  (si  IN 
new_schcdulc))  I  (-  (si  IN  old_schedule)  &  si  IN  new_schedulc)  I 
(old_schedule  [si]  ncw_schcdule  [si]  &  ch  (si)  =  ncw_schedule  [si])) 

END 

d.  Assignments 

DEFINITION  assignment  ••  concepts  for  assigning  a  designer  to 

a  step 

INHERIT  ECS_state_niodel 
INHERIT  designer 

CONCEPT  curr_assign  (s:  step  ,  d:  designer)  VALUE  (b:  boolean) 


WHERE  b  <»>  active  (s)  &  predecessor.finished  (s)  &  status  (d)  =  free  & 
dcsigncr_cxpeitisc_lcvcl  (d)  >»  stcp_cxpcrtisc_lcvcl  (s) 

CONCEPT  predecessor.finished  (s:  step)  VALUE  (b:  boolean) 

WHERE  b  <=>  ALL  (si:  step  SUCH  THAT  active  (si) :: 

-precedes(sl. «.  dep_graph)) 

CONCEPT  active  (s:  step)  VALUE  (b:  boolean) 

WHERE  b <s>  status  (s)  IN  (scheduled,  assigned) 

CONCEPT  check.due.completion  (s:  schedule^type)  VALUE  (w;  warning,  ss:  set 
(step)) 

WHERE  ALL  (sf  step  ::  st  IN  ss  <»>  st  IN  s  &  status  (st)  *  assigned  & 
s(st).scheduled_finish_tiine  <»  cuirent.time) 

CONCEPT  warning:  string 

WHERE  warning  »  “the  following  steps  missed  their  finish  time,  either  commit  or 
inaease  their  estimated  duration” 

END 


2.  Behavior  Model 
MACHEME  Evolution_Control_System 
INHERIT  designer.inteiface 
INHERIT  manager.interface 
END 
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MACHINE  common  interface 


FIGURE  31.  Stimulus_Response  diagram  for  the  common  interface 
INHERIT  ECS_state_modcl 

MESSAGE  show_stcps  (p:  componcnt_rcfcrencc  SUCH  THAT  topjevcl(p), 

t:  stcp_status) 

-  display  all  steps  with  the  given  status  of  the  given  prototype 
WHEN  component_in_graph(p,  graph) 

REPLY  (s:  sequence  {step}) 

WHERE  ALL  (»:  step::  i  IN  s  <=>  step_in_graph(i,  graph)  &  ( status  (i)  =  1 1  t=all )) 
OTHERWISE  REPLY  EXCEPTION  no_suchj)rototype 


MESSAGE  create_step  (p:  component_rcfercncc  SUCH  THAT  top_level(p), 

primaryjnput :  set  {componcnt_rcfcrcncc)) 

WHEN  component_in_graph(p,  graph)& 

coniponcnt_in_graph  (c:  component_rcferencc  SUCH  THAT  c  IN  primaryjnput, 
graph) 

REPLY  (s:  step 
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WHERE  unique.stepjd  (s) 

TRANSITION  primary.input  »bind(s,  prim,  ‘primaryjnput), 
secondaiyjnput  =  bind(s,  scc.*secondaryJnput), 
affected.modules  »  bind  (s,  aff,  *affected_modules), 

-  affected  modules  and  secondary  inputs  are  automatically  generated 
add_step_node(s,  graph),  only.change  (graph,  *graph,  s) 

WHEN  component_in_graph(p,  graph)& 

-  component_in_graph  (c;  component.reference  SUCH  THAT  c  IN 
primaryjnput,  graph) 

REPLY  EXCEPTION  undeflned.input 
OTHERWISE  REPLY  EXCEPTION  no_such_prototype 


MACHINE  editjnterface 

-  This  interface  includes  all  the  messages  required  to  modify  the  step  attributes,  the 

-  management  constraints,  and  the  designer_pool  data. 

INHERIT  ECS_state_model 


MESSAGE  add_primary_input  (f  step  SUCH  THAT  topjevel  (i), 

c:  specific_component_reference) 

~  this  is  used  to  add  primary.input  to  the  step  as  they  become  known 
~  normally  a  step  has  one  primary  input  except  in  case  of  a  merge  when  it  has 
-  two  or  more 

WHEN  -  component_in_graph  (c,  graph) 

REPLY  EXCEPTION  undefmed.input 

WHEN  step_in_graph(i,graph)  &  component_in_graph  (c,  graph) 

REPLY  done 
TRANSITION 

primaryjnput » bind(i,  *primary_input  (i)  U  {c},  *primary_input). 
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only.change  (i,  *i,  c) 

OTHERWISE  REPLY  EXCEPTION  no.such.stcp 

MESSAGE  add.affected.modules  (i:  step  SUCH  THAT  top_lcvel  (i), 

c:  component.reference) 

-  this  is  used  to  add  affected.modules  to  the  step  as  they  become  known 

-  since  the  calculated  set  is  an  approximation 
WHEN  -  component_in_graph  (c,  graph) 

REPLY  EXCEPTION  undefined_input 

WHEN  step_in_graph(i,graph)  &  ~  (i  IN  schedule) 

REPLY  done 

TRANSITION  only^change  (i,  *i,  c), 

affected.modules  3  bind(i.  *affected_inodules  (i)  U  (c),  *affected_modules) 
WHEN  i  IN  schedule  &  feasible_schedulc  (update.schedule  (*schedule,  i)) 
REPLY  (schedule.changes  (‘schedule,  schedule)) 

~  the  schedule  must  be  updated  to  maintain  the  invariant 
TRANSITION  only^change  (i,  *1,  c),  only_changc(*schedule,  schedule,  i), 
affected.modules  3  bind(i,  ‘affected.modules  (i)  U  (c),  ‘affected.modules) 
WHEN  i  IN  schedule  &  SOME  (s:  schedule_type  SUCH  THAT 
s  3  update.schedule  (‘schedule,  i)::  -  feasible_schedule  (s)  & 

"  manager.confumation  (s)) 

-  ask  for  manager  confirmation  only  if  a  feasible  schedule  cannot  be  reached 
REPLY  changes_undone 

WHEN  i  IN  schedule  &  SOME  (s:  schedule_type  SUCH  THAT 
s  3  update_schedule  (‘schedule,  i):: 

~  feasible.schedule  (s)  &  manager.confirmation  (s)) 

REPLY  (schedule.changes  (‘schedule,  schedule)) 

TRANSITION  only_change  (i,  ‘i,  c),  only_change(‘schedule,  schedule,  i). 


affected.modules  »  bind(i.  •affectcd_modules  (i)  U  ( c  | ,  *affccted_modulcs) 

deadline  » least.slips  (^deadline,  schedule) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 

••  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 

—  schedule 

OTHERWISE  REPLY  EXCEPTION  no_such_step 


MESSAGE  add_secondary_input  (i:  step  SUCH  THAT  topjevel  (i), 

c:  component_reference) 

this  IS  used  to  add  secondaryjnput  to  the  step  as  they  become  known 
WHEN  -  componentjn^^ph  (c,  graph) 

REPLY  EXCEPTION  undef!ned_input 
WHEN  stepjn_graph(i,graph)  &  -  (i  IN  schedule) 

REPLY  done 

TRANSITION  only.change  (i.  *i.  c), 

secondaryjnput  =  bind(i,  *secondary_input  (i)  U  (c),  *secondaryJnput) 
WHEN  i  IN  schedule  &  feasible.schedule  (update.schedule  (*schedule,  i)) 
REPLY  (schedule^changes  (^schedule,  schedule)) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 
TRANSITION  only_change  (i,  *i,  c),  onIy_change(*schedule,  schedule,  i), 
secondaryjnput »  bind(i.  ^secondaryjnput  (i)  U  (c),  •secondaryjnput) 
WHEN  i  IN  schedule  &  SOME  (s:  schedule.type  SUCH  THAT 

s  =  update_schedule  (•schedule,  i)::  -  feasible_schedule  (s)  & 

-  manager.connrmation  (s)) 

-  ask  for  manager  confirmation  only  if  a  feasible  schedule  cannot  be  reached 
REPLY  changes_undone 

WHEN  i  IN  schedule  &  SOME  (s:  schedule_typc  SUCH  THAT 
s  =  update.schedule  (•schedule,  i):; 
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~  feasible.schedule  (s)  &  manager.confumation  (s)) 

REPLY  (schedule.changes  ('''schedule,  schedule)) 

TRANSITION  only.change  (i,  *i,  c),  only_change(*schedule,  schedule,  i), 
secondary.input »  bind(i.  '^secondary.input  (i)  U  (c).  *secondaiy .input) . 
deadline  » least.slips  (^deadline,  schedule) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 
~  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 
••  schedule 

OTHERWISE  REPLY  EXCEPTION  no_such_step 


MESSAGE  delete_primary_input  (i:  step  SUCH  THAT  topjevel  (i). 

c:  component.reference) 

-  this  is  used  to  delete  inputs  from  the  step’s  primary  input 
WHEN  WHEN  -  component_in.graph  (c.  graph) 

REPLY  undefinedjnput 
WHEN  stepjn.graph(i  .graph) 

REPLY  done 

TRANSITION  primary.input  =  bind(i,  *primary_input  (i)  -  (c). 
*primaiy_input), 

only.change  (i.  '*i.  primary.input) 

OTHERWISE  REPLY  EXCEPTION  no.such.step 


MESSAGE  delete_affectcd_modules  (i:  step  SUITH  THAT  topjevel  (i). 

c:  componcnt.refcrence) 

-  this  is  used  to  delete  those  affected.modules  that  do  not  need  change. 
WHEN  -  component  Jn.graph  (c.  graph) 

REPLY  undefmed.object 

WHEN  step_in.graph(i.graph)  &  status  (i)  =  approved 
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REPLY  done 

TRANSITION  only  .change  (i,  *i,  c), 

affeaed .modules  «  bind(i.  *affected_modules  (i)-  {c},  *affccicd_modulcs) 
WHEN  i  IN  schedule 

REPLY  (schedule.changes  (*schedulc.  schedule)) 

TRANSITION  only.change  (i.  *i.  cs). 

affected.modules  «  bind(i,  *affected_inodules  (i)-  {c|,  *affectcd_modules) 
OTHERWISE  REPLY  EXCEPTION  no.such.step 

MESSAGE  delete.secondaryjnput  (i:  step  SUCH  THAT  top.level  (i). 

c:  component.refcrence) 

~  this  is  used  to  delete  secondary  inputs  to  a  step 
WHEN  -  component_in.graph  (c,  graph) 

REPLY  EXCEPTION  undefined.input 
WHEN  step_in.graph(i,graph)  &  -  (i  IN  schedule) 

REPLY  done 

TRANSITION  only.changc  (i,  •!,  c), 

secondary.input  3  bind(i,  *secondary.input  (i)  -  (c),  *secondary_input) 
WHEN  i  IN  schedule 

REPLY  (schedule.changes  (^schedule,  schedule)) 

TRANSITION  only.change  (i,  •!,  secondary.input), 
secondaiy.input  s  bind(i,  *secondary.input  (i)  -  (c),  *secondary_input) 

••  the  schedule  must  be  updated  to  maintain  the  invariant 
OTHERWISE  REPLY  EXCEPTION  no.such.step 

MESSAGE  update j)riority  (i:  step  SUCH  THAT  top.levcl  (i),  p:  natural) 

WHEN  i  IN  steps  &  (p  >  priority  (il)  SUCH  THAT  il  IN  precedence  (i)) 
REPLY  EXCEPTION  priority.conflict 
WHEN  step.inj$raph(i.graph)  &  ~  (i  IN  schedule) 


REPLY  done 

TRANSITION  priority  =  bind  (i,  p,  *priority),  only_changc  (i,  *i,  p) 
WHEN  i  IN  schedule  &  feasiblc_schedulc(updatc_schcdulc  (‘schedule,  i)) 
REPLY  (schedule.changes  (‘schedule,  schedule)) 

TRANSITION  priority  »  bind  (i.  p,  ‘priority) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 
WHEN  i  IN  schedule  &  SOME  (s:  schedule.type  SUCH  THAT 

s  *  update.schedule  (‘schedule,  i)::  -  feasible_schedule  (s)  & 

-  manager.conflrmation  (s)) 

REPLY  change.undone 

WHEN  i  IN  schedule  &  SOME  (s:  schedule.type  SUCH  THAT 
s  a  update.schedule  (‘schedule,  i)::  -  feasible_schedule  (s)  & 
manager.confirmation  (s)) 

REPLY  (schedule.changes  (‘schedule,  schedule)) 

TRANSITION  priority  =  bind  (i,  p,  ‘priority), 
deadline  a  least.slips  (‘deadline,  schedule) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 

~  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 

-  schedule 

OTHERWISE  REPLY  EXCEPTION  no_such_step 


MESSAGE  update_precedence  (i;  step  SUCH  THAT  topjevel  (i),  p:  set  (step)) 
WHEN  stepjn _graph(i,graph)  &  (priority  (i)  >  priority  (il)  SUCH  THAT 
il  INp) 

REPLY  EXCEPTION  priority_conflict 
WHEN  stcpjn_graph(»  *  ih)&  -  (i  IN  schedule) 

REPLY  done 

TRANSITION  precedence  *  bind  (i,  p,  ‘precedence),  only_changc  (i,  ‘i,  p) 
WHEN  i  IN  schedule  &  feasible_schedulc  (update.schedule  (‘schedule,  i)) 
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REPLY  (schedule.changes  (*scheduie.  schedule)) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 
TRANSITION  precedence  *  bind  (i,  p.  ^precedence) 

WHEN  i  IN  schedule  &  SOME  (s:  schedule.type  SUCH  THAT 
s  s  update^schedule  C^schedule,  i);:  ~  feasible.schedule  (s)  & 

*•  manager.confumation  (s)) 

-  ask  for  manager  confirmation  only  if  schedule  invalidated 
REPLY  change.undone 

WHEN  i  IN  schedule  &  SOME  (s:  schedulc.type  SUCH  THAT 
s  «  update.schedule  (^schedule,  i)::  *•  feasible.schedule  (s)& 
manager.confirmation  (s)) 

REPLY  (schedule.changes  (^schedule,  schedule)) 

TRANSITION  precedence  »  bind  (i,  p,  ^precedence), 
deadline  » least.slips  (*deadline,  schedule) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 

-  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 

schedule 

OTHERWISE  REPLY  EXCEPTION  no.such.stcp 

MESSAGE  update.deadline  (i:  step  SUCH  THAT  topjevel  (i),  didrne) 

WHEN  stepjn_graph(i,graph)  (i  IN  schedule) 

REPLY  done 

TRANSITION  deadline  «  bind  (i,  d,  deadline) 

WHEN  i  IN  schedule  &  feasible.schedule  (update.schedule  (*schedule,  i)) 
REPLY  (schedule.changes  (‘schedule,  schedule)) 

TRANSITION  deadline  =  bind  (i,  d,  deadline) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 
WHEN  i  IN  schedule  &  SOME  (s:  schedu!c_type  SUCH  THAT 

s  s*  update.schedule  (‘schedule,  i)::  ~  feasible.schedule  (s)  & 

-  manager.confirmation  (s)) 


REPLY  change.undone 

WHEN  i  IN  schedule  &  SOME  (s:  schedule.type  SUCH  THAT 
s  s  update.schedule  (^schedule,  i)::  ~  feasible.schedule  (s)  & 
manager.conftrmadon  (s)) 

REPLY  (schedule.changes  (^schedule,  schedule)) 

TRANSITION  deadline  a  least.slips  (^deadline,  schedule) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 

-  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 
~  schedule 

OTHERWISE  REPLY  EXCEPTION  no^such.step 

MESSAGE  update.esdmated.duradon  (i:  step,  t:  natural) 

WHEN  step  Jn_graph(i,graph)  &  -  (i  IN  schedule) 

REPLY  done 

TRANSITION  esdmated.duradon  =  bind  (i,  t,  *esdmated_duradon) 
WHEN  i  IN  schedule  &  feasible_schedule(update_schedulc  (•schedule,  i)) 
REPLY  (schedule.changes  (*schedule,  schedule)) 

TRANSITION  esdmated.duradon  »  bind  (i,  t,  •esdmated.duradon) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 
WHEN  i  IN  schedule  &  SOME  (s:  schedule_type  SUCH  THAT 

s  s  update.schedule  (•schedule,  i):: "  feasible.schedule  (s)  & 

-  manager.confirmadon  (s)) 

REPLY  change.undone 

WHEN  i  IN  schedule  &  SOME  (s:  schedule.type  SUCH  THAT 
s  =  update.schedule  (•schedule,  i)::  feasible.schedule  (s)  & 
manager.confirmadon  (s)) 

REPLY  (schedule.changes  (•schedule,  schedule)) 

TRANSITION  esdmated.duradon  =  bind  (i,  t,  •esdmated.duradon), 
deadline  =  least.slips  (•deadline,  schedule) 

••  the  schedule  must  be  updated  to  maintain  the  invariant 
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••  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 
••  schedule 

OTHERWISE  REPLY  EXCEPTION  no_such_step 

CONCEPT consistent_deadIines  (dl,  d2:  map  (step.time))  VALUE  (b;  boolean) 
WHERE  b  <*>  ALL  (s:  step::  dl(s)  »d2  (s)) 

-  for  dl  to  be  consistent  with  d2,  either  the  deadline  of  each  step  in  dl  is 

~  equal  to  that  of  the  same  step  in  d2  or  relaxed  to  be  equal  to  its  calculated 

-  finish  time. 

CONCEPT  valid_slip  (dl,  d2:  map  {step.time))  VALUE  (b:  boolean) 

WHERE  b  <3>  consistent.deadlines  (dl.  d2)  & 

ALL  (si,  s2:  step:: 

dl(sl)  =  none  -=  d2(sl)  &  dl(s2)  -=  none  »>  priority  (s2)  >=  priority  (si)) 
••  new  deadline  map  is  valid  only  if  the  relaxed  deadlines  are  the  lowest 

-  priority  deadlines 

CONCEPT  slips_more  (dl.  d2:  map  (step.time))  VALUE  (b:  boolean) 

WHERE  b  <=>  consistent.deadlines  (dl,  d2)  &  dl  "=  d2 

CONCEPT  least_slips  (dl:  map  (step.time).  s:  schcdule_type) 

VALUE  (d2:  map  {step,time)) 

WHERE  valid.slip  (d2,dl)  &  feasible.schedule  (s,  d2)  & 

ALL  (d3:  map  (step.time):: 

slips_more  (d2,  d3)  &  consistent_deadlines  (d3,dl)  => 

-  SOME  (si:  schedule_type:.fcasible_schedule  (si,  d3)) 

CONCEPT  only_change  (x  y:  any,  Sattribute.names:  identifier) 

VALUE  (b:  boolean) 
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-•  Tnie  if  x  and  y  can  differ  only  in  the  listed  attributes. 

WHERE  ALL  (id:  identifier:  x.id  ~=  y.id  =>  id  IN  attribute_nam»;s) 


END 


3.  Manager  Interface 
MACHINE  designer_pool_view 
INHERIT  ECS_state_modcl 
INHERIT  conunon.inteiface 
MESSAGE  add_designer  (d:  designer) 

—  adding  a  designer  to  the  designer_pool 
WHEN  -  (d  IN  designers_pool) 

!?EPLY  (schedule.changes  (‘schedule,  schedule)) 

TRANSITION  designcrs_pooI  =  *designers_pool  U  (d) 

••  the  schedule  must  be  updated  to  use  the  new  designer  and  maintain  the 

-  invariant 

-  adding  a  designer  cannot  invalidate  a  feasible  schedule 
OTHERWISE  REPLY  EXCEPTION  designer.exists 


MESSAGE  drop_designer  (d:  designer) 

-  remove  designer  from  the  dcsigners_pool 
WHEN  d  IN  designer_pool  &-  (d  IN  schedule) 

REPLY  done 
TRANSITION 

designers_pool  =  *designcrs_pool  -  (d) 

WHEN  d  IN  designer_pool  &  d  IN  schedule 
REPLY  warning.  confirmation_rcquircd 
WHEN  d  IN  designcr_pool  «St  d  IN  schedule  & 

SOME  (s;  schedule.type  SUCH  THAT  s=  update.schedule  (‘schedule,  d):: 
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feasible_schedule  (s)  &  manager.conftrmation  (s)) 

REPLY  (schcclulc_changcs  (*schedulc,  schedule)) 

TRANSITION  designer_pool  =  *designer_pool  -  |d| 

WHEN  d  IN  designer_pooI  &  d  IN  schedule  &  SOME  (s;  schcdulc_typc  SUCH 

THAT 

s  =  update_schedulc  (‘schedule,  d)::  -  feasible_schcdule  (s)  & 

-  manager.confirmation  (s)) 

REPLY  change.undone 

WHEN  d  IN  designer_pool  &  d  IN  schedule  & 

SOME  (s;  schedule_typc  SUCH  THAT  s  *  update.schedule  (‘schedule,  d);: 

-  feasible.schedule  (s)  &  manager.confirmation  (s)) 

REPLY  (schedulc^changes  (‘schedule,  schedule)) 

TRANSITION  designcrs_pool  =  ‘designers_pool  •  {d), 
deadline  a  least.slips  (‘deadline,  schedule) 

••  the  schedule  must  be  updated  to  maintain  the  invariant 

-  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 
"  schedule 

OTHERWISE  REPLY  EXCEPTION  no.such^designer 


MESSAGE  designer_expertise_ level  (d:  designer,  e:  exp_Ievel) 
~  modify  the  designer's  expertise  level 

WHEN  d  IN  designer_pool  &  -  (d  IN  schedule) 

REPLY  done 

TRANSITION  designer_expertisejevel  (d)  =  e, 
only_change  (‘d,  d,  dcsigncr_expcrtise_levcl) 

WHEN  d  IN  designer_pool  &  d  IN  schedule  & 
feasible.schedule  (update.schedule  (‘schedule,  d)) 

REPL'r  (schcdule_changes  (‘schedule,  schedule)) 
TRANSITION  designer_expertise_level  (d)  =  e. 
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only_changc  (*d,  d,  dcsigner_cxpertisc_levcl) 

WHEN  d  IN  designer_pool  &  d  IN  schedule  Sl 

SOME  (s:  schedule_type  SUCH  THAT  s=  update.schedule  (*schedule,  d):: 

-  feasible.schedule  (s)  &  -  manager.confirmation  (s)) 

REPLY  change.undone 

WHEN  d  IN  designer_pool  &  d  IN  schedule  & 

ALL  (s:  schedule_type  SUCH  THAT  s=  update.schedule  (*schedule,  d);: 

-  feasible.schidule  (s)  &  manager_confirmation  (s)) 

REPLY  (schedule.changes  (^schedule,  schedule)) 

TRANSITION  designer_expertise_level  (d)  =  e, 
only_change  (*d.  d.  designer_expertiscjevel) 
deadline  » least.siips  (^deadline,  schedule) 

-  the  schedule  must  be  updated  to  maintain  the  invariant 

—  The  deadline  changes  is  kept  to  the  minimum  required  to  get  a  feasible 
••  schedule 

OTHERWISE  REPLY  EXCEPTION  no.such.designer 

MESSAGE  show_designers  (dp:  set  (designer)) 

•>  display  all  the  designers  in  the  designer’s  pool 
WHEN  dp/=  {} 

REPLY  (s:  set  (designers)) 

WHERE  ALL  (d:  designer ::  d  IN  s  <=>  d  IN  dp) 

OTHERWISE  REPLY  EXCEPTION  no_such_prototype 

END 


MACHINE  managerjnterface 

INHERIT  user  --  defines  User_class,  uses 
INHERIT  designer_pool_view 
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INHERIT  common_interface 
INHERIT  edit  Jntcrfacc 
INHERIT  ECS_state_model 


MESSAGE  approve_stcp  (s:  step  SUCH  THAT  top_Ievel(s)) 

-  used  to  approve  a  step  which  triggers  the  change  propagation  via  the 
••  calculation  of  the  affected  n\odules 
WHEN  status  (s)  =  proposed 

REPLY  (ss;  set  (component_refcrcnce)) 

TRANSITION  status  =»  bind  (s,  approved.  *status),  auto_create_substcp  (s) 
..  advance  the  step  status  to  “approved” 

..  calculate  the  set  of  modules  affected  by  the  step 
•<  create  an  atomic  substep  for  each  affected  module 
OTHERWISE  REPLY  EXCEPTION  no_such_proposed_stcp 


MESSAGE  show_schedule  (p:  prototype.name) 

-  display  the  full  schedule 

WHEN  prototype  (p)  IN  prototypes 
REPLY  (s:  schedule_type) 

WHERE  s  *  schedule 

OTHERWISE  REPLY  EXCEPTION  no_such_prototype 


MESSAGE  schcdulc_step  (s:  step) 

WHEN  status  (s)  =  approved  & 

SOME  (sj;  step  SUCH  THAT  S]  part_of  s;:  estimated.duration  (sj)  =  0) 
REPLY  estimated_duration_not_speciried 
WHEN  status  (s)  =  approved  &  feasiblc_schcdulc  (update.schedule  (*schedulc, 
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REPLY  (schedule.changes  (•schedule,  schedule)) 

TRANSITION  status  =  bind  (s.  scheduled,  •status) 

—  the  schedule  must  be  updated  to  maintain  the  invariant 

WHEN  status  (s)  =  approved  &  SOME  (sch:  schedule_type  SUCH  THAT 
sch  “  update.schedule  (•schedule,  s):;-  feasiblc_schedulc  (sch)  St 

-  manager.confirmation  (sch)) 

REPLY  step_is_not_scheduled 

WHEN  status  (s)  =  approved  &  SOME  (sch:  schedule_type  SUCH  THAT 
sch  a  update.schedule  (•schedule,  s)::  -  feasible_schedule  (sch)  & 
manager.confirmation  (sch)) 

REPLY  (schedule_changes  (•schedule,  schedule)) 

TRANSITION  status  =  bind  (s,  scheduled,  •status) 
deadline  =  least.slips  (•deadline,  schedule) 

—  the  schedule  must  be  updated  to  maintain  the  invariant 

-  The  deadline  changes  arc  kept  to  the  minimum  required  to  get  a  feasible 
"  schedule 

OTHERWISE  REPLY  EXCEPTION  no_such_approvcd_stcp 


MESSAGE  abandon.step  (s:  step) 

WHEN  stcp_in_graph(s,graph)  &  -  (s  IN  schedule) 

REPLY  done 

TRANSITION  status  »  bind  (s,  abandoned,  •status) 
WHEN  s  IN  schedule  &  sums  (s) » scheduled 

REPLY  (schedule_changes  (*schedule,  schedule)) 
TRANSITION  sums  =  bind  (s,  abandoned,  •sums) 

••  the  schedule  must  be  updated  to  maintain  the  invariant 
WHEN  s  IN  schedule  St  sums  (s)  »  assigned 

SEND  (“step  abandoned”,  s)  TO  schedule  [s].dcsigncr 
REPLY  (schedule_changes  (•schedule,  schedule)) 
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TRANSITION  status  »  bind  (s,  abandoned,  ^status), 
removejnput^edges  (s.  graph) 

—  remove  the  abandoned  step  from  the  schedule  and  re-assign  its  designer 

—  remove  version  bindings  of  inputs  to  the  step 
OTHERWISE  REPLY  EXCEPTION  no^such.step 


MESSAGE  suspend.step  (s:  step) 

WHEN  s  IN  schedule  &  status  (s)  s  scheduled 

REPLY  (schedule.changes  (^schedule,  schedule)) 
TRANSITION  status  3  bind  (s,  approved,  ^status) 

—  the  schedule  must  be  updated  to  maintain  the  invariant 
WHEN  s  IN  schedule  &  status  (s) »  assigned 

SEND  (“step  suspended”,  s)  TO  schedule  (s).designer 
REPLY  (schedule.changes  (‘schedule,  schedule)) 
TRANSITION  status  =  bind  (s.  approved,  ‘status). 

remove_input_edgcs  (s.  graph) 

••  the  schedule  must  be  updated  to  maintain  the  invariant 
OTHERWISE  REPLY  EXCEPTION  no_such_scheduled_step 


MESSAGE  commit_step  (s:  step  SUCH  THAT  top_level(s)) 

-  committing  a  top  level  step  means  adding  its  output  components  to  the  configuration 
graph 

"  and  releasing  tiie  committed  version  to  the  public  use. 

WHEN  status  (s)  =  assigned  & 

ALL  (si;  step  SUCH  THAT  part_of  (si.  s)::  status  (si)  =  completed) 
REPLY  done 

TRANSITION  status  (s)  =  completed. 

-  The  new  protoytpe  configuration  should  be  created  at  this  point 
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OTHERWISE  REPLY  EXCEPTION  no_such_issigned_stcp 


MESSAGE  managcr.confirmation  (s:  schcdulc_type) 

REPLY  (b:  boolean) 

-  b  is  true  if  the  manager  responds  positively  after  being  notified  of 
~  schedule  invalidation  (deadline.change). 


CONCEPT  manager.notified  (s:  schedule_type) 

VALUE  (dc:  set  {deadline.change  )) 

WHERE  ALL(st:  step::  st  IN  dc  <«>  deadline  (st)  <  estimated_finish_time(st)) 

CONCEPT  deadline.change:  type 
WHERE  deadline.change  » 

tuple  {st::  step,  deadline  (st)  estimated.finish.time  (st)::  time) 

CONCEPT  auto.create.substep  (s:  step)  VALUE  (ss:  set  {step)) 

WHERE  ALL  (st:  step,  c:  component.reference ::  st  IN  ss  <=>  c  IN  affected.modules 
(s)  &  primary.input(st)  -  c  &  atomic  (st)) 

CONCEPT  manager  User.class 
WHERE  ALL  (m:  manager::  uses  (m,  ECS)) 

-  managers  use  the  ECS 
manages  (m,  designers) 
manages  (m,  steps) 

END 
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4.  Designer  Interface 

The  designer  interface  with  ECS  enables  the  designer  to  view  the  steps  in  a  given 
prototype  with  a  given  status  and  get  the  sub-steps  assigned  to  him.  This  interface  also 
enables  the  designer  to  create  a  step  or  a  sub-step  of  an  assigned  step,  updating  any  of 
the  step  attributes,  as  well  as  committing  the  assigned  sub-step. 

MACHINE  designerjnterface 
INHERIT  common_interface 
INHERIT  ECS_state_model 

MESSAGE  commit_step  (s;  step,  cc  ;  set  |spccific_component_reference) ) 

—  committing  an  atomic  step  means  storing  its  output  component  in  the 

—  shared  data  space,  configuring  it,  and  making  it  visible  only  to  the  design  team 
WHEN  status  (s)  =  assigned  &  current_time  <=  scheduled_finish_time  & 

ALL  (o:  object::  o  IN  cc  &  dcsigncr.confumation  (o)  &  complete  (o)) 
REPLY  done 

TRANSITION  ALL  (o:  object::  o  IN  cc::  add_output_edgc  (s,  o.  graph), 
status  s  bind  (s,  completed,  ^status) 

WHEN  status  (s)  *  assigned  &  current_time  <*  schedulcd_finish_time  & 

ALL  (o:  object::  o  IN  cc  &  designer_confirmation  (o)  &  -  complete  (o)) 
REPLY  (ss:  sequence  {step}) 

WHERE  ALL  (o:  object  SUCH  THAT  o  IN  cc  &  -complete  (o):: 

EXIST  (si:  step  SUCH  THAT  si  IN  ss  &  primary_input  (si)  »  o  & 
status  (si)  s  proposed)) 

TRANSITION  ALL  (o:  object::  o  IN  cc::  add_output_cdgc  (s,  o,  graph), 
status  =  bind  (s,  completed,  ^status) 

WHEN  status  (s)  *  assigned  &  currcnt_time  >  scheduled_rinish_time  & 

ALL  (o:  object::  o  IN  cc  &  designcr_confirmation  (o)  &  complete  (o)) 
REPLY  (schedule_changes  (^schedule,  schedule)) 

TRANSITION  ALL  (o:  object::  o  IN  cc::  add_output_cdgc  (s,  o,  graph). 


status  »  bind  (s,  completed,  ^status) 

—  schedule  must  be  updated  to  maintain  the  invariant 
WHEN  status  (s) »  assigned  &  current.dme  >  scheduled_rinish_time  & 
ALL  (o:  object::  o  IN  cc  &  dcsigncr_confirmation  (o)  &  -complete  (o)) 
REPLY  (schedule.changes  (‘schedule,  schedule),  ss:  sequence  (step)) 
WHERE  ALL  (o:  object  SUCH  THAT  o  IN  cc  &  -complete  (o) :: 
EXIST  (si:  step  SUCH  THAT  si  IN  ss  &  primary_input  (si)  =  o  & 
status  (si)  3  proposed)) 

TRANSITION  ALL  (o:  object::  o  IN  cc::  add_output_cdgc  (s,  o,  graph), 
status  a  bind  (s,  completed,  ‘status) 
schedule  must  be  updated  to  maintain  the  invariant 
OTHERWISE  REPLY  EXCEPTION  no_such_assigned_sub-step 


MESSAGE  designer.confirmation  (s:  schedule.typc) 

REPLY  (b:  boolean) 

-  b  is  true  if  the  designer  responds  positively  after  a  warning  of  schedule 
••  invalidation 


CONCEPT  designer:  User_class 

WHERE  ALL  (d:  designer::  uses  (d,  ECS)) 
-designers  use  the  ECS 

ALL  (s:  step::  SOME  (d:  designer::  perform  (d,  s))) 
END 


5.  Type  Time 

INHERIT  equality  (date) 

MODEL  (day,  month,  year,  hour,  minute:  nat) 

INVARIANT  ALL  (d:time::  1  <»  d.day  <=  31  &  1  <»  d.month  <*  1 1  & 


0  <a  d.year  <=  99  &  0  <«  d.hour  <=  23  &  0  <=  d.minute  <»  59  &d  <  none) 
MESSAGE  create  (d  m  y,  h,  min:  nat) 

WHEN  1  <»  d  <5*  31  &  1  <=  m  <=  12  &  0  <“  y  <=  99  & 

0  <=  h  <a  23  &  0  <=  min  <»  59 
REPLY  (dl:time) 

WHERE  dl. day  »  d,  dl. month  s  m,  dl.year  ^  y,  dl.hour  sh, 
d  1. minute  s  min 

OTHERWISE  REPLY  EXCEPTION  illegal.datc 


MESSAGE  equal  (dl  d2:time) 

REPLY  (b:  boolean) 

WHERE  b  <s>  dl.day  a  d2.day  &  dl.month  *  d2.month  & 
dl.year  »  d2.year  &  dl.hour  «  d2.hour  & 
dl. minute  >  d2.minute 
MESSAGE  “<“(dl  d2:time) 

REPLY  (b:  boolean) 

WHERE  b  <»>  0  <  (d2.year  •  dl.year)  MOD  100  <  50 
I  dl  .year  »  d2.year  &  dl  .month  <  d2.month 
I  dl.year  »  d2.year  &  dl.month  »  d2.month  &  dl.day  <  d2.day 
I  dl.year  »  d2.year  &  dLmonth  *  d2.month  &.  dl.day  »  d2.day  & 
dLhour  <  d2.hour 

I  dl.year  «  d2.year  &  dl.month  ^  d2.month  &  dl.day  -  d2.day  & 
dl.hour  s  d2.hour  &  dl.minute  <  d2.minute 
-Note  12/31/99  <01/01/00 

—  <  is  a  total  ordering  on  any  time  interval  less  than  50  years  long 

-  but  it  is  not  transitive  on  longer  intervals 
MESSAGE  “<=“(dl  d2:time) 

REPLY  (b:  boolean) 

WHEREb<=>dl  <d2ldl  =d2 
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CONCEPT  none:  time 

"  constant  representing  absence  of  a  deadline  constraint 

END 


B.  DESIGN  DATABASE  SCHEMA 

1.  Class  Step 
step.h 

#ifndef  _ STEP.H 

#define  _ STEP.H 

#include  <Object.h> 

# include  <'iype.h> 

#include  <List.h> 

#include  <Re£erence.h> 
#include  <stream.h> 

extern  •C 
{ 

#include  <sys/tiine.h> 

# include  <sys / types .h> 
#include  <string.h> 

) 

#ifndef  _ ^COMPONENT.H 

#include  "component .h* 

#endi£ 

#include  "support.classes .h" 


class  COMP.REFERENCE: public  Object 
{ 

private : 

char*  priv.name; 

int  version.no; 

int  variation.no; 

public : 

COMP.REFERENCE ( APL  *  theAPL ) ; 
virtual  Type  *getDirectType ( ) ; 
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COMP_REFERENCE ( ) ; 

void  set_priv_name (char*  name) { 
pr  i  v_name=ncime ; 

} 

char*  get_priv_name ( ) { 

return  priv.name; 

> 

void  set_version_no { int  value) { 
version_no  =  value; 

) 

int  get.version_no ( ) { 

return  version_no; 

} 

void  set_variation_no (int  value) { 
variation^no  *  value; 

} 

int  get„variation_no ( ) { 

return  variation_no; 

} 

void  displaycomp ( ) ; 

}; 


class  STEP  :  public  Object 
{ 

private  ; 


int 

step_type; 

int 

step_id; 

int 

indicator; 

int 

in_degree ; 

int 

estimated_duration; 

int 

priority; 

char* 

designer; 

int 

status ; 

int 

required_expertise_level ; 

Time 

deadline; 

Time 

start_time; 

Time 

f inish_time; 

time_t 

date_created; 

time_t 

date_of_current_status  ; 

Reference 

base_version; 
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Reference 

Reference 

Reference 

Reference 

Reference 

Reference 

Reference 


primary_input_list ; 
secondary_input_list ; 
output_list; 
affected_module_list; 
substep_list; 
part_of ; 

preceded_by_list ; 


public : 


STEP(APL  *theAPL) ; 

STEP(char*  name,  int  s_id) ; 
virtual  void  putObject (OC_Boolean 
deallocate=FALSE) ; 

virtual  void  deleteObject (OC_Boolean 
deallocate=FALSE) ; 

virtual  void  Destroy (Boolean  abort  =  FALSE); 
virtual  Type  *getDirectType( ) ; 


int  get_step_type{ ) {return  step^type;) 
void  set_step_ type ( int  type) {step_type  =type;) 
void  displayStep_id( ) ; 
int  get_step_id( ) { 

return  step_id; 

} 


int  get_indicator { ) { 

return  indicator; 


) 

void  set^indicator ( int  type) ( 
indicator  =type; 


) 


int  get_in_degree ( ) { 

return  in_degree; 

) 

void  set_in_degree ( int  type) { 
in_degree  =type; 

} 

void  set_estiinated_duration(int  value)  ( 
estiinated_duration=  value; 

} 

int  get_estiinated_duration  ( )  { 

return  estimated_duration; 

) 
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void  setjpriority ( int  value) ( 
priority*  value; 

} 

int  get_priority ( ) ( 

return  priority; 

} 

void  set_designer  (char*  a_ncune)  { 
designer=a_naine; 

} 

char*  get_designer ( ) { 

return  designer; 

} 

void  3et_statu3 (int  value) { 

3tatus  *  value; 

} 

int  get_3tatu3 ( ) { 

return  status; 

) 

void  set_required_expertise_level (int  value) { 
required_expertise_level=value; 

} 

int  get_required_expertise_level ( ) { 

return  required_expertise_level ; 

} 

void  set_deadline (Time  value) { 
deadline  =  value; 

} 

Time  get^deadline ( ) { 

return  deadline; 

} 

void  set_start_time (Time  value) { 
start_time  =  value; 

} 

Time  get_start_time ( ) { 

return  start_time; 

} 

void  set_f inish_time (Time  value) { 
finish_time  ■=  value; 

} 
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Time  get_f inish_time ( ) { 

return  finish_time; 


} 


//  set  creation  time 

time_t  setCreationDate( ) ; 

//  get  creation  time 

time_t  getCreationDate ( ) { 
return  date_created; 

) 

time_t  get_date_of_curr«-nt_status  ( )  ( 

return  date_o  current_status; 

) 


void  set_date_of_current_status ( ) { 
date_of_current_status  = 

setCreationDate ( ) ; 


} 


//  get  a  list  of  primary  input. 

List*  primary^input ( ) { 
return  (List*) 

pt imary_input_list . Binding ( this ) ; 

) 

//  reset  a  list  of  primary  input 

void  primary_input (  List*  parts)  { 

primary_input_list .Reset (parts,  this) ; 

} 


//  get  a  list  of  secondary_input . 

List*  secondary_input ( ) { 
return  (List*) 

secondary_input_list .Binding (this) ; 

} 

//  reset  a  list  of  secondary  input 

void  secondary_input (  List*  parts)  { 

secondary_input_l ist . Reset (parts ,  this ) 

) 

//  get  a  list  of  output 
List*  output  0 { 
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return  (List*  )output_li£*'  .  Binding  ( this  )  ; 


//  reset  a  list  of  output 

void  output!  List*  parts)  { 

output_list . Reset (parts ,  this) ; 

} 

//  get  a  list  of  af f ected_moduies 
List*  af f ected_module ( ) { 
return  (List*) 

af  f  ected_module_list .  Binding  ( this 


//  reset  a  list  of  af f ected_inodules 

void  af f ected_module (  List*  parts)  ( 

affectt?d_n\odule_list  .Reset  (parts,  this); 


//  get  a  list  of  substeps 
List  *  substep ( ) { 

return  (List*) 

substep_list  .  Biriding  ( this  ) 


//  reset  a  list  of  substeps 

void  substep(  List*  parts)  { 

substep_list .Reset (parts,  this; ; 


get  a  list  of  preceded_by 
List  •  preceded_by ( ) { 
return  (List*) 

preceded_by_l isc . Binding ! thi ; 


res^^t  a  list  ot  prec  ded_by 
v:ad  preceded_by!  List*  parts)  •; 

preceded_by_l ist . Reset (parts,  this 


void  set_paren*_step (STEP*  otherstep)* 

part_of .Reset ( otherst ep,  this  ;  , 
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void  set_base_version {COMP_REFERENCE*  my_comp) { 
base_version .Reset (my_comp, this) ; 

} 

COMP_REFERENCE*  aet  base_version ( ) ; 
void  add_substep  (STEP*  iny_step)  ; 
void  add_predecessor (STEP*  rny_step)  ; 

//void  add_successor (STEP*  iny_step)  ; 

void  add_primary_input  (COMP_REFERENCE*  iny_comp)  ; 

void  delete_primary_input  (char *  coiip.name)  ; 

void  add_secondary_input  {COMP_REFERENCE*  rny_comp)  ; 

void  delete_secondary_input  ( char*  comp_naine)  ; 

void  add_ouCput  (COMPONENT*  my_coinp)  ; 

void  add_af f ected_moduies (COMP_REFERENCE* 

rny_comp)  ; 

void  delete_af  fected_modules  (char*  comp_nanie)  ; 

void  show_primary_input ( ) ; 

void  show_secondary_inpuL ( ) ; 

void  show_af  f  ected_inodules  ( )  ; 

void  show_output ( )  ; 

void  show_substeps ( ) ; 

void  show_preceding_steps { ) ; 

STEP*  get_parent_step ( ) ; 

)  ; 

#endif  //  _ STEP_H 


step.cxx  ••••••••••••••••••••••••••••••••••••• 

•ifndef  _ DDBDEFINES_H 

••include  “ddbdef  ines  ...* 

“endi f 

include  'Type.h> 

^include  ‘Object. h> 

^include  <GlobalEntities .h> 

■include  -Catatase-b 

■  include  •  Cire  or>' .  h  > 

extern  *C' 

( 

char  *getenv ( const  char  * )  ; 

■  include  •  strings. 

■include  •ctype.h> 

■include  <stddef.h> 

^include  ‘String. hj- 
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} 

#ifndef  _ COMPONENT_H 

#include  *  component .h* 
iendif 

#ifndef  _ STEP_H 

#include  "step.h* 
#endif 


// 


STEP; :STEP(APL  *theAPL) rChject ( theAPL) , 

deadline ( ( APL* ) 0) , start^time ( ( APL* ) 0 ) . f inish_t ime ( ( APL* ) 0 ) 


STEP: : STEP (char*  name,  int  s_id) : 

Object (name) , deadline (0, 0 , 0 , 0, 0) ,  start^time ( 0 , 0, 0, 0 , 0 ) , 
finish_time(0, 0, 0, 0, 0) 

{ 

initDirectType ( (Type* ) OC_lookup ( " STEP" ) ) ; 

step_type  =  0; 

indicator  =  0; 

in_degree  =  0; 

step_id  =  s_id; 

estimated_durat ion  =  0; 

priority  =  0; 

designer  =(char*)0; 

status  =  0; 

required_expertise_level  =  0; 
date_created  =  setCreationDate( ) ; 
date_of_current_status  =  0; 
base_version .  initTotJuli  ( )  ; 
part_of . initToNull f ) ; 
primary_inpuc_l ist . Init (new 

List ( (Type* )OC_lookup ' "COMr_PEFERENCE" ) ) , this ) ; 
secondary_input_l 1st . Init (new 

List  (  (Type*  )OC_lookup  (  •COMP_REFEFEriCE"  /  )  ,  this;  ; 
output_li  '-t .  Init  (new 

List  (  (Type*  ]  OC_lookup  i  "COMPCtiErJT" )  )  ,  this  i  ; 
af  f ected_mc'dule_i ist  .  Init  (new 

List ( (Type*) OC_ lookup ( "COMP.REFERENCE" ) : , this ! ; 
substep_list . Init (new 
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List( (Type* )OC_lookup{“ STEP-) ) .this) ; 

preceded_by_list . Init (new 

List ( (Type* )OC_lookup ( “STEP* ) ) . this) ; 

} 

Type  *STEP: :getDirectType ( ) 

{ 

return  (Type* )OC_lookup ( “STEP" ) ; 

} 

void  STEP: rputObject (OC_Boolean  deallocate) 

{ 

//saves  structure  of  the  component  lists 

( (List* ) primary_input_list . Binding ( this ) ) - 
>putObject (FALSE) ; 

( (List  * ) secondary_input_list . Binding ( this ) ) - 
>putObject (FALSE) ; 

( (List* ) output_list .Binding(this) ) - 
>putObject (FALSE) ; 

(  (List* ) af fected_module_list . Binding (this) ) - 
>putObject (FALSE)  ; 

( (List*) substep^list .Binding(this) ) - 
>putObject (FALSE) ; 

( (List*)preceded_by_list .Binding (this) ) - 
>putObject (FALSE) ; 

II  ( (List* ) successor_list . Binding ( this) ) - 
>putObject (FALSE)  ; 

//  saves  the  component  itself 

Object : 


) 


putObject (deallocate) ; 


void  STEP: rdeleteObject (OC^Boolean  deallocate) 

{ 

//deletes  structure  of  the  component  lirts 

( (List  * ) pr imary_input_list .Binding (this) ) - 
>delet eOb^ect (deallocate) ; 

( (List  * ) secondary_input_list . Binding ( this) ' - 
>deleteOb ject (deallocate)  ; 

( (List  * ) output_list . Binding ( this) ) - 
^deleteOb ject (deallocate)  ; 

( (List  * ) aff ected_module_l ist . Binding ( this ) ? - 
^deleteObject (deallocate)  ; 

( (List* ) substep_list . Binding ( this ) ) - 
>deleteOb ject (deallocate) ; 


16K 


( (List* )preceded_by_list .Binding (this) ) - 
>deleteObject (deallocate) ; 

//  ( (List  * ) successor_list . Binding (this) ) - 

>deleteObject (deallocate) ; 

//  deletes  the  component  itself 

Object : 

deleteObject (deallocate) ; 

} 

void  STEP: : Destroy (Boolean  aborted) 

{ 

Entity*  ent ; 

ent  =  primatY_input^list .Binding (this) ; 
delete  ent; 

ent  =  secondary_input_list .Binding (this) ; 
delete  ent; 

ent  =  output_list . Binding (this) ; 
delete  ent; 

ent  =  affected_module_list .Binding ( this) ; 
delete  ent; 

ent  =  substep_list .Binding (this) ; 
delete  ent; 

ent  =  preceded_by_list .Binding (this) ; 
delete  ent; 

//  ent  s  successor_list.Binding(this) ; 
delete  ent; 
if  (aborted)  Object: 

Destroy (aborted) ; 

} 

//  set  creation  time 

time_t  STEP : : setCreationDate ( ) 

{ 

time_t  *mytloc  =0; 
time_t  theTime; 

return  theTime  =  time (mytloc) ; 

) 

void  STEP: :add_substep (STEP*  otherstep) 

{ 

List  *chi.''d  nodes  =  (List 
* ) sub3ter_list .Binding (this) ; 

if  ( : this) 
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step\n* ; 


{ 

cout  «  '•<ERROR:  cannot  add  a  substep  to  a  null 


step\n‘ ; 


return; 

} 

if  ( !child_nodes) 

{ 

cout  <<  "<ERROR:  cannot  add  a  null  substep  to  a 
return; 

} 


child_nodes“>Insert (otherstep) ; 
child_nodes->putObject ( ) ; 
putObject ( ) ; 


void  STEP: :add_predecessor (STEP*  otherstep) 

{ 

List  *the_nodes  =  (List 
* ) preceded_by_list .Binding (this) ; 


\n“ 


stepNn* ; 


) 


if  ((this) 

{ 

cout  «  ''<ERROR:  cannot  add  a  substep  to  a  null  step 
return; 

) 

if  (!the_nodes) 

{ 

cout  <<  “<ERROR:  cannot  add  a  null  substep  to  a 
return; 

} 

this->set_in_degree(this->get_in_degree( ) +1) ; 
the_nodes->Insert (otherstep) ; 
the_nodes->putObject ( ) ; 
putObject ( ) ; 


void  STEP:  :add_primary_input  (COMP_REFERENCE*  my_coinp) 
{ 

List  *the_nodes  =  (List 
*  )  priinary_input_list .  Binding  ( this )  ; 


if  (Ithis) 

{ 

cout  <<  “<ERROR:  cannot  add  a 
COMP_REFERENCE  to  a  null  step\n“; 

return; 

} 

if  (!the_nodes) 

{ 

cout  «  “<ERROR;  cannot  add  a  null 
COMP_REFERENCE  to  a  step\n* ; 

return ; 

} 

the_nodes->Insert  (rny_comp)  ; 
the_nodes->putObject ( ) ; 

//  putObjectO; 

} 

void  STEP: :add_secondary_input (COMP_REFERENCE*  nv_comp) 

{ 

List  *the_nodes  =  (List 
* ) secondary_input_list .Binding ( this) ; 

if  (ithis) 

{ 

cout  <<  •<ERROR:  cannot  add  a 
COMP_REFERENCE  to  a  null  step\n"; 

return; 

} 

if  ( ! the_nodes ) 

{ 

cout  «  "<ERROR:  cannot  add  a  null 
COMP_REFERENCE  to  a  stepNn"; 

return; 

} 

the_nodes->Insert  (iny_coinp)  ; 
the_nodes->putObject ( ) ; 

//  putObjectO; 

} 

void  STEP:  :add_output  (COMPONEi'IT*  nry^conip) 

{ 

List  *the_nodes  =  (List 
*) output_list . Binding (this ) ; 
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if  (Ithis) 

{ 

cout  <<  ‘'<ERROR:  cannot  add  a  COMPONENT 

to  a  null  step\n‘; 

return; 

} 

if  ( ! the_nodes ) 

{ 

cout  <<  '‘<ERROR:  cannot  add  a  null 
COMPONENT  to  a  step\n“; 

return; 

) 

the_nodes->Insert  (iny_comp)  ; 
the_nodes->putObject ( ) ; 

//  putObjectO; 

} 

void  STEP:  ;add_af  f ected^modules  (COMP_REFERENCE*  iry_comp) 

{ 

List  *the_nodes  =  (List 
*'affected_inodule_list  .Binding  (this)  ; 

if  (Ithis) 

{ 

cout  «  "<ERROR:  cannot  add  a 
COMP_REFERENCE  to  a  null  stepNn"; 

return; 

} 

if  (!the_nodes) 

{ 

cout  «  "<ERROR:  cannot  add  a  null 
COMP_REFERENCE  to  a  Step\n"; 

return; 

} 

the_nodes->Insert  (iny_coinp)  ; 
the_nodes->putObject ( ) ; 

//  putObject(); 

) 

void  STEP: :delete_primarY_input (char*  iny_comp) 

{ 

(X_Boolean  FOUND=FALSE; 

List  *my_list  = 

( List* )  priinary_input_list .  Binding  ( this )  ; 
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Listiterator  nty_iterator  (my^list)  ; 
COMP_REFERENCE  *the_comp; 
while (rny_iterator  .moreData( )  &&  '.FOUND) 
{ 


the_comp  = 

(COMP_REFERENCE*) (Entity *) my_iterator ( ) ; 

if  (strcinp(the_coinp  ->get_priv_name  ( )  , 

iny_coinp)  ==0)  { 

iny_l  i  s  t  -  >Remo  ve  ( my_l  i  s  t - 

>Index(the_comp) ) ; 

FOUND  =  TRUE; 

} 


} 


) 


void  STEP: :delete_secondary_input (char*  rny_comp) 

{ 


OC_Boalean  FOUND=FALSE; 

List  *iny_list  = 

(List*) secondary_input_list . Binding (this) ; 

Listiterator  my^iterator (my^list) ; 

COMP_REFERENCE  *  the.comp ; 

while  (iny_iterator  .inoreData  ( )  &&  !  FOUND) 

{ 

the_coinp  = 

(COMP_REFERENCE*) (Entity* ) my^iterator ( ) ; 
if ( strcmp ( the_comp  ->get_priv_name ( ) , 
niy_comp)  ==0)  { 


nTy_list->Reinove  (iny_list- 
>Index  (the_coinp) )  ; 

FOUND  a  TRUE; 


void  STEP: :delete_affected_modules (char*  my_comp) 

{ 

OC_Boolean  FOUND=FAL£E; 

List  *my_list  = 

(List*)af fected_module_list .Binding (this) ; 
Listiterator  iny_iterator  (iny_list )  ; 
COMP_REFERENCE  *the_coinp; 
while (my_iterator.moreData ( ) &&  (FOUND) 

{ 

the_comp  = 
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(COMP^REFERENCE*) (Entity* ) my_iterator ( ) 
if (strcmp(the_comp  ->get_priv_name ( ) , 
iny_comp)  ==0)  { 

nTy_list->Reinove  (niy_list- 
>Index ( the_comp ) ) ; 

FOUND  =  TRUE; 


COMP_REFERENCE*  STEP : : get_base_version { ) 

{ 

return 

(COMP_REFERENCE* ) base^version . Binding ( this ) ; 

) 

STEP*  STEP:  :get_j>arent_step( ) 

{ 

return  ( STEP* ) part_of . Binding ( this ) ; 

} 

void  STEP :  :  show_priinary_input  ( ) 

{ 

List  *rny_list  * 

(List*)primarY_input_list .Binding (this) ; 
Listiterator  niy^iterator  (niy_list)  ; 

COMP_REFERENCE  *the_con?5; 

//  cout«  "Primary  inputs:  *; 

while  (iny_iterator  .moreData  ( ) ) 

{ 

the_comp  = 

(COMP_REFERENCE* )  (Entity*  )iTy_iterator  ( ) 
the_comp  ->  di sp lay comp () ; 

} 

} 


void  STEP : : show_secondary_input ( ) 

{ 

List  *my_list  = 

(List*) secondary_input_list .Binding (this) ; 
Listiterator  my_iterator (my_list ) ; 
COMP_REFERENCE  *  the_comp ; 

//  cout«  my_list->Cardinality ( )  <<"\n"; 
while (my_iterator. moreData ( ) ) 


( 


the_comp  = 

(COMP_REFERENCE*)  ( Entity*  ) iny_iterator  ( ) 
thf?_coinp  ->  di  splay  comp  I )  ; 

} 

) 

void  STEP: : show_af f ected_modules ( ) 

{ 

List  *iny_list  = 

( List * ) af  f ected_module_list . Binding ( this ) ; 
Listiterator  iny_iterator  (my_list )  ; 

COMP_REFERENCE  *the_comp; 

//  cout«  my_list->Cardinality  ( )  <<’‘\n‘; 
while (iny_iterator.moreData() ) 

{ 

the_comp  a 

(COMP.REFERENCE*) (Entity* ) my^iterator ( ) 
the_comp  ->  displaycomp ( ) ; 

) 

} 

void  STEP : : show_output ( ) 

{ 

List  *iny_list  =  ( List *)output_list. Binding! this )  ; 
Listiterator  nty_iterator(iny_list)  ; 

COMPONENT  *the_COinp; 

//  cout«  "\nstep  outputs: 

while  (iny_iterator  .moreData  ( ) ) 

{ 

the_comp  a 

(COMPONENT*)  (Entity*)iny_iterator()  ; 
cout  <<the_comp  ->CompnentNanie  ( )  ; 

) 

) 

void  STEP: : show_substeps ( ) 

{ 

List  *iny_list  =  (List*)  substep_list  .Binding  (this) 
Listiterator  nty_iterator  (my_list )  ; 

STEP  *the_step; 

//  cout<<  iny_list->Cardinality  { )  <<"\n*; 
while  (iny_iterator  .moreData  ( )  ) 

{ 

the_step  a 
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(STEP*)  (Entity* )iny_iterator  ( )  ; 

the_step->  displayStep_id ( ) ; 


} 


) 


void  STEP : : shcw_preceding_steps ( ) 

{ 

List  *niy_list  = 

(List*  )  preceded_l3y_list . Binding  (this)  ; 

Listiterator  iny_iterator  (iny_list )  ; 

STEP  *the_step; 

//  cout<<  "Xnstep  predecessors: 
int  i=0; 

//  cout<<  iny_list->Cardinality  ( )  <<*\n"; 
while  (iny_iterator  .moreData  ( ) ) 

{ 


i  =  i>l; 
the_step  = 

(STEP*)  ( Entity* ) iny_iterator  ( )  ; 

cout  «the_step->  get_step_id  ( )  ; 
if  (i<  my_list->Cardinalicy ( ) ) 
cout 


) 


} 


void  STEP: :displayStep_id ( ) 

{ 

cout  «  step_id  <<* 

} 

COMP_REFERENCE:  :COMP_REFERENCE(APL  *theAPL)  -.Object  (theAPL) 

{ 

} 

COMP_REFERENCE : : COMP_REFERENCE ( ) 

{ 

initDirectType  (  (Type*  )  OC_loo)cup  ( *COMP_REFERENCE" )  )  ; 
priv_name= (char* ) 0 ; 
version_no=0 ; 
variation_no=0 ; 

} 


Type* 


COMP_REFERENCE : : getDirectType ( ) 


{ 

return  (Type* ) OC_lookup ( •COMP_REFERENCE‘ ) ; 

) 

void  COMP_REFERENCE ; : displaycomp { ) 

{ 

cout  <<priv_naine  <<“\n*; 

) 

step_OperaUons.h 

#ifndcf  _STEP_OPERATIONS_H 
#dcnne  _STEP_0PERAT10NS_H 

#include  “componenth” 

#include  “stcp.h” 

#include  “support_classcs.h” 

#includc  “tcxt_objccth” 

char*  gct_rcd_of_extcnsion(chax*  comp_name); 

void  CTeatc_stcp(char*  dbnamc.char*  protoname,  char*  comp.namc); 

void  show_step(char*  dbname.int  stcp_id); 

void  show.stcpsCchar'  dbnamc.char*  aNamc); 

void  Add_primary_input(ini  stcp_id,char*  comp_namc); 

void  Delctc_primary_input(int  stcp_id.char*  comp_namc); 

void  Add_sccondary_input(int  stcpjd.char*  comp_name); 

void  Dclctc_sccondary_input(int  stcp_id,char*  comp_name); 

void  Add_affccted_moduIes(int  step_id.char*  comp_namc); 

void  Delcte_affcctcd_modulcs(int  stcp_id,char*  comp_name); 

void  Update_preccdence(int  step_id,int  prcccding_step_id); 

void  Update_priority(int  stcp_id,int  value); 

void  Updatc_expertisc_level(int  stcp_id,int  value); 

void  Update_dcadlinc(int  stcp_id,char*  iheDaic); 

void  Updatc_cstimatcd_duration(int  stepjd.int  value); 
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void  Updatc_start_timc(char*  dbnamc,int  step_id,char*  thcDatc); 

void  Updatc_finish_tinnc(char*  dbname,int  step_id,char*  thcDate); 

void  Updatc_status(char*  dbnamc.int  stcp_id.int  value); 

void  Updatc_dcsigner(char*  dbnamc.int  stepjd.char*  aName); 

void  gct_scheduUng_data(char*  dbname.  int  stcp_id,  char*  curr_time); 

void  get_Schcd_data_l(char  *dbnamc,char*  listName.char*  cur_timc,char* 

d_namc); 

void  get_scheduling_data_2(char*  dbname,  char*  curT_timc,  char*  d_name); 

void  get_commit_data(char*  dbname,  int  stcpjd); 

void  set_sccondary_input(STEP*  a_stcp,char*  compPath); 

void  set_affectcd_modules(STEP*  a_stcp,  char*  protoNamc.char*  comp  .name), 

void  creatc_substep(char*  dbname.int  stepjd.char*  p_input, 

char*  d_namc,char*  theDate,  int  duration); 
STEP*  create_substep(STEP*  thc_stcp,  char*  p_input); 
void  auto_create_substeps(char*  dbnamc.int  stcp_id); 
void  commit_stcp(char*  dbnamc,int  stcp_id); 
void  commit_substep(char*  dbname.int  step_id); 

void  rcmove_step_from_schcdulc(char*  dbnamc.char*  stcp_id,char*  myDate); 
void  rcmove_step_from_schcd(int  step_id); 
void  Updatc_Stcp(char*  dbname,int  stepjd,char*  theDate, 
char*  pJnputA,  char*  p_inputD. 
char*  sJnputA,  char*  sJnputD, 
char*  a_inputA,  char*  aJnputD, 
int  pri_value,  int  prec_vlaue. 
int  dur_vlauc,  int  cxpjcvvcl); 
void  stcp_update(int  step_id,char*  theDate. 

char*  pJnputA,  char*  p  JnputD, 
char*  sJnputA.  char*  sJnputD, 
char*  a JnputA,  char*  aJnputD, 
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int  pri_valuc,  int  prec_vlauc. 
int  dur_vJaue.  int  exp_lcvel); 
void  save_stcp_old_valucs(STEP*  a_stcp); 
void  Undo_step_update(char*  dbname.int  step_id); 
void  dump_step_ccmponcnts(char*  dbnamc.  int  stcp_id); 
void  find_assigned_step(char*  dbname,  char*  user); 
void  suspend_abandon_step(char*  dbname.int  stcp_id.  int  new_status), 
void  updatc_basc_versions(int  stepjd.char*  tempi); 
void  Update_deadline(char*  dbname.int  step.id); 
void  Early_waming{char*  dbname.  char*  myTime); 


#cndif  //  _STEP_0PERAT10NS_H 


st®p_Operations.cxx  •**•*•**•••••*•••**••*•••*••••*•••••*•*••**••*•**•***• 

#inclucie  <Database.h> 

#include  <Directory.h> 

#include  <string.h> 

#include  <Set.h> 

#include  <stdlib.h> 

#include  "Ky_String .h“ 

#include  * component .h" 

#include  “step-h* 

#include  "support_classes .h“ 

#include  "text_object .h" 

# include  "comp_Operations .h* 

# include  "step^Operations .h" 

^include  "sched.h" 

# include  “schedOp.h" 

#include  "person. h" 

static  char  *Level(3]  =  {"Low",  "Medium",  "High"}; 
static  char  ‘Status [6]  = 

{ "proposed" , "approved" , "scheduled" , "assigned" , "completed" , "a 
bandoned" } ; 

extern  char  ‘thepath; 
extern  int  warning_time; 
extern  char  ‘dirNamePtr ; 
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extern  char  *DESIGN_DATABASE_DIRECTORY; 


char*  get_red_of_extension  (char*  conip_name) 

( 

char  niy_word  1 1 2 8 )  ; 

char  'word (7); 

char*  separator=* . “ ; 

wordfO] =strtok (comp_name, separator) ; 

int  i=0; 

while (word(il  !=  NULL) { 
i  =  i  +  .l; 

word  ( i  ]  =strto)c  (NULL,  separator )  ; 

} 

int  k  =  i-3; 

if(k==0)  return  word(0]; 
else( 

if (k==l) { 

sprint f  (iny_word,  "%s%s%s* ,  word(O)  ,  "  .  ,word[l]  )  ; 
return  mi'_word; 

} 

else  { 

if (k==2) { 

sprint f  (nry_word,  ''%s%s%s%s%s'  ,word(0] ,  “  .  “  ,word[l]  ,  " .  “  .word [2  1 
)  ; 

return  iny_word; 

} 

else{ 

sprintf  (iny_word,  "%s%s%s%s%s%s%s"  ,word[0] ,  " .  ",word(l) , 

• . " , word [2] , “ . ■ , word [ 3  J ) ; 
return  iny’_word; 

} 


STEP*  f ind_step ( int  step_id) 

{ 

OC_Boolean  FOUND = FALSE; 

Set  *aSet  =  (Set  * ) OC_lookup ( "step_set " ) ; 

//  Abort  if  there  is  no  set 
if  (  aSet  ==  NULL  )  { 

cout  <<  “there  is  no  steps  in  database  yet.\n“; 
return  NULL; 


) 

//  couC  <<  aSet -''Name  ( )  <<  ■  has  ”  <<  aSec.->Cardinality  I )  <• 
"  items . \n\n" ; 

//  Ask  the  set  object  for  an  iterator 
Iterator*  aniterator  =  aSet->getIterator ( ) ; 

STEP*  the_step; 

//  For  each  item  in  the  iterator 
while  (anIterator->moreData  () &&  .'FOUND)  { 

//  Get  the  item 

the_step= ( STEP* ) (Entity  * ) (anIterator->operator ( ) ( ) ) 
if (the_step->get_step_id( ) ==step_id) 

•^OUND  =  TRUE; 

} 

if (FOUND) 

return  the_step; 

else 

return  tJULL, 


void  f ind_assigned_step (char*  dbname,  char*  user) 

{ 

OC_open (dbname) ; 

OC_transactionStart ( ) ; 

OC_Boolean  FOUND  =  FALSE; 

Set  *aSet  =  (Set  * ) OC_lookup ( *step_set “ ) ; 

Iterator*  aniterator  =  aSet->getIterator 0 ; 

STEP*  the_step; 

//  For  each  item  in  the  iterator 
while {anIterator->moreData ( )  &&  (FOUND)  { 
the_step= (STEP* ) (Entity  *) (anIterator->operator ( ) ()); 
if (the_step->get_designer ( )  (=0) { 

char*  salan=  new  char (strlen (the_step->get_designer ( ) ) +1 ) 
strcpy ( salah, the_step->get_designer ( ) ) ; 

if (strcmp (salah, user) ==0  &&  the_step->get_status ( ) ==3  && 
the_step->get_indicator ( ) ==0 ) { 

FOUND  =  TRUE; 
char  nTy_name  [16]  ; 

sprintf  (iny_name,  "%s%s%d"  ,  * . " ,  '•step_" ,  the_step- 
>get_step_id( ) )  ; 

cout  <<  “F“  <<  "\n*; 

cout  <<  iny_name  <<  "\n"; 

cout  <<  the_step->got_step_id ( )  <<  “\n"; 

} 
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) 


) 

if (! FOUND)  cout  <<  -N-  «  *\n“; 

OC_transactionCoininit  ( )  ; 

OC_close ( ) ; 

} 

void  dump_step_componenCs {char*  dbname.int  step_id) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( )  ; 
char  nry_name(8]  ; 
char  protonaTne[64]  ; 

STEP*  the_scep=  f ind_step (step_id) ; 

sprintf  (iny_naine,  “%d“ ,  the_step->get_step_id ( )  )  ; 

My_String 

teinp=My_String  ( “  . " )  +My_String  ( “step_‘ )  +My_String  (iny_name)  ; 
dirNamePtr  =(char*)  temp; 

COMP_REFERENCE*  iny_comp=  the_step->get_base_version () ; 
char  *temp2=my_comp->get_priv_name () ; 
int  var=iny_comp->get_variation_no  ( )  ; 
int  ver=my_comp->get_version_no ( ) ; 
sprintf (protoname, "%s  %d:%d“,  temp2,var,  ver) ; 

List  *iny_list=the_step->primary_input  ( )  ; 
COMP_REFERENCE*  my_ref  a (COMP^REFERENCE* ) my.list- 
>getEntityElement (0) ; 

char*  check  =  my_ref->get_priv_name()+strlen(my_ref- 
>get_priv_name ( ) ) -10; 

if (strcmp (check, * .spec.psdl" ) ==0) { 

My_String  temp=My_String  (iny_ref->get_priv_name  ( )  )  -10; 
char*  comp_name  =(char*)  temp; 

DumpComponent (protoname, comp_name) ; 

} 

else{ 

My_String  temp=My_String{my_ref->get_priv_name ( ) ) -9; 
char*  comp_name  =(char*)  temp; 

DumpComponent (protoname, comp_name) ; 

List  *n^_list=the_step->secondary_input ( ) ; 
Listiterator  my_iterator (my_list ) ; 
while {my_iterator .moreData ( ) ) 

{ 

COMP_REFERENCE* 

my^comp=  (COMP_REFERENCE* )  (Entity* ) iTiy_iterator  ( )  ; 

My_String  temp=My_String {my_comp->get_priv_name ( ) ) - 

10; 
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char*  comp_name  =(char*)  temp; 
Dump_Spec_Filel (protoname, comp_name) ; 

} 

) 

the_step->set_indicator ( 1 ) ; 
the_step->putObject ( ) ; 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 

} 

void  Ear ly_warning (char*  dbname,  char*  myTime) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( )  ; 
int  my_id; 

Time  T1 (myTime); 

List  *aList  =  (Lis^  *) OC_lookup ( “My Schedule" ) ; 
if(aList  !=  NULL)  { 

Iterator*  iny_iterator  =  aList->getIterator  ( )  ; 
//  For  each  item  in  the  iterator 
while (my_iterator->moreData ( ) )  { 

Schedule*  next Assignment  =  (Schedule*) 

(Entity*)  ( (  *iny_iterator)  () )  : 

if(  nextAssignment->AssignmentFinish ( ) -  T1  <= 
warning_time) 

{ 

sscanf (nextAssignment->Name ( ) , " %d“ ,  &my_id) 
STEP*  the_step=f ind_step (iny_id)  ; 
if ( the_step->get^status ( ) ==  3  &&  the_step- 
>get_indicator ( )  !=  2) 

{ 

cout  <<  the_step->get_step_id ( ) <<  "\n“; 
cout  «  the_step->get_designer ( )  «  *\n' 
the_step->set_indicator(2) ; 
the_step->putObject ( ) ; 

) 

} 

} 

} 

OC_transactionCommit { ) ; 

OC_close ( ) ; 


void  show_step (char*  dbname,  int  step_id) 
{ 

OC_open ( dbname ) ; 


183 


OC_transactionStart ( ) ; 

STEP*  the_step=f ind_step (step_id)  ; 
if{the_step  !=  NULL) { 

COMP_REFERENCE*  rny_coinp  =  che_step- 
>get_baGe_version ( ) ; 

cout  <<iny_comp->get_priv_naine  ( )  <<“  “ 

<<  nty_comp->get_variation_no  ( ) 

<<•  *  <<  rny_conip->get_version_iio  ( )  <<"\n“; 
cout  <<the_step->get_estimated_duration ( )  <<“\n“; 
cout  <<the_step->get_priority ( )  <<  “\n"; 
cout  <<Level [the_step  -> 
get_required_expertise_level ( ) ] 

«  "Xn"; 

cout  «Status  (the_step->get_status  ( )  1  <<  "\n“; 
cout  «the_step->get_designer  ( )  «  "Xn"; 
cout  <<the_step->get_deadline  ( )  .ma)ceString  ( )  “Xn"; 

cout  <<the_step->get_start_time  ( )  .ina)ceString  ( )  << 

“Xn"  ; 

cout  <<the_step->get_f  inish_time  ( )  .malceString  ( )  << 

“Xn*  ; 

the_step->show_primary_input ( ) ; 

List*  iny_list=the_step>>secondary_input ( ) ; 
cout  «  rny_list->Cardinality  ( )  <<  “Xn“; 
the_step->show_second3ry_input ( ) ; 
niy_list=the_step->af  fected_module  ( )  ; 
cout  <<  iny_list->Cardinality  { )  <<  “Xn“; 
the_step->show_af  f  ected_inodules  ( )  ; 
rny_list=the_step->substep  ( )  ; 
int  n  =  my_list->Cardinality ( ) ; 
cout  <<  iny_list->Cardinality  ( )  <<  “Xn“; 
the_step->show_substeps ( ) ; 
nTy_list=the_step->preceded_by  ( )  ; 
if  (n==0) 

cout  <<iny^list->Cardinality  ( )  <<  “Xn"; 
else 

cout  <<  *Xn“  <<iny_iist->Cardinality  ( )  <<  "Xn“; 
the_step->show_preceding_steps ( ) ; 
cout  <<  “Xn"  <<  “Xn“; 


) 

OC_transactionCoininit  ( )  ; 
OC_close ( )  ; 

} 


void  get_coininit_data  (char*  dbname,  int  step_id) 
{ 

OC_open (dbname) ; 
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OC_transactionStart ( )  ; 

STEP*  the_step=f ind_step{step_id) ; 
if(the_step  !=  NULL) { 

the_step->get_base_version  ( )  -  >d  i  sp  lay  coir, p  ( i  ; 
the_step->show_priin3ry_input  ( )  ; 
the_step->show_output ( ) ; 

) 

OC_transactionCoinmic  ( )  ; 

OC_close { )  ; 

} 

void  get_scheduling_data_2 (char*  dbname,  char* 
curr_t ime , char*  d_name ) 

{ 

OC_open (dbname) ; 

OC_transactionStart ( )  ; 
int  my_id; 

Time  T1 (curr_time) ; 

Time  T(0,0,0,0,0) ; 

List  *aList  a  (List  * ) OC_loo)<up ( “MySchedule“ )  ; 
ifOList  !=  NULL)  ( 

Iterator*  my_iterator  =  aList->getIterator ( ) ; 

//  For  each  item  in  the  iterator 
while (my_iterator->moreData { ) )  { 

Schedule*  next Assignment  =  (Schedule*) 

(Entity* ) ( ( *my_iterator) ( ) ) ; 

sscanf  (nextAssignment->Name( ) ,  "%d" ,  Simy_id)  ; 

STEP*  the_step=find_step(iny_id); 
if ( the_step->get_status ( ) ==2  II 

(the_step->get_status ( ) == j  && 
strcmp (the_step->get_designer ( ) ,d_name)==0) ) { 

cout  «  the_step->get_step_id ( ) <<  "\n"; 
int  T2=  the_step->get_deadline ( )  -  Tl; 
if  (T2  <  0) 

cout  <<"1000"  <<  "\n"; 
else 

cout  <<T2  <<  "\n"; 

cout  <<the_step->get_priority ( )  <<  "Xn"; 

cout  <<the_step->get_estimated_duration ( )  <<"\n"; 

cout  <<"{"; 

the_step->show_preceding_steps ( ) ; 
cout  «"}  \n"; 
cout  < < Leve 1 [ t he_s tep- 
>get_required_expertise_level  ( )  ]«  “\n"; 

cout  «  the_step->get_in_degree ( )  <<  "\n"; 

} 
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} 

} 

OC^transactionCommit ( ) ; 
OC_close ( ) ; 

} 


void  get_scheduling_data (char*  dbname,  inc  step_id,  char* 
curr_time) 

{ 

OC_open { dbname ) ; 

OC_transactionStart ( )  ; 
int  niy_id; 

Time  T1 (curr_timel ; 

Time  T(0,0,0,0,0); 

List  *aList  =  (List  •)OC_lookup( "My Schedule ") ; 
if(aList  !=  NITLL)  { 

Iterator*  my_iterator  =  aList->getIterator ( ) ; 

//  For  each  icem  in  the  iterator 
while (my_iterator->moreData ( ) )  { 

Schedule*  next Assignment  =  (Schedule*) 

(Entity*) ( ( *my_iterator ) ()); 

sscanf (next Assignment ->Name( ) , "%d*,  4my_id) ; 

STEP*  the_step=f  ind_step(nty_id)  ; 
if (the_step->get_status ( ) ==2) { 
cout  «  the_step->get_step_id( )<<  "\n“; 
int  T2=  the_step->get_deadline ( )  -  Tl; 
if  (T2  <  0) 

cout  <<"1000"  «  "Nn"; 
else 

cout  «T2  <<  *\n“; 

cout  «the_step->get_priority  ( )  <<  “\n"; 

cout  «the_step->get_estimated_duration ( )  <<"\n" 

cout  <<•{■; 

the_step->show_preceding_steps ( ) ; 
cout  <<*}  \n'; 
cout  <<Level [the_step- 
>get_required_expertise_level ( ) ] 

«  "Xn"; 

cout  <<  the_step->get_in_degree ( )  <<  "\n"; 

) 

} 

} 

if(step_id  !=0) 

{ 
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0) 


STEP*  a_step=find_step(step_id) ; 
i£ (a_step  !=  NULL) { 

if {a_step->get_status ( )  !=  1  II  a_step->get_step_type ( ) 


cout  <<  "Cannot  schedule  None  approved  step  or  part 
of  a  top  step"  <<  "in"; 
else{ 

List*  nTy_list=a_step->substep  ( )  ; 

Listlterator  iTiy_iterator  (my_list )  ; 

STEP  *thG_step; 

while  (iTiy_iterator  .moreData  ( )  ) 

{ 

the_step  =  (STEP*)  (Entity*  )iTTy_iterator  ()  ; 
cout  <<  the_step->get_step_id ( ) <<  "\n"; 
int  T2=  the_step->get_deadline ( )  -  T1 ; 
if  (T2  <  0) 

cout  <<"1000"  <<  “\n"; 
else 

cout  <<T2  <<  “\n*; 

cout  <<the_step->get_priority ( )  <<  "\n"; 

cout  «the_step->get_estiinated_duration  ( )  <<"\n"; 

cout  <<"{*; 

the_step  -'>show_preceding_steps  ( )  ; 
cout  «")  \n"; 
cout  <<Level [the_step- 
>get_required_expertise_leval ( ) ] 

<<  "Xn"; 

cout  <<  the_step->get_in_degree ( )  <<  "\n"; 


) 

) 


) 

} 

OC_transactionCoinmit  ( )  ; 
OC^close ( )  ; 

} 


void  get_Sched_data_l (char  *dbname, char *  listName, char* 
cur_t ime , char  *  d_name ) 

{ 

OC_open (dbname) ; 

OC_transactionStart ( ) ; 
int  nty_id; 

List  *aList  =  (List  * ) OC_lookup ( listName) ; 
if(aList  ==  NULL)  { 

//  cout  <<  "No  Such  Schedule  ...\n"; 
OC_transactionCominit  ( )  ; 
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OC_close ( )  ; 
return; 

} 

Time  T1 (cur_time) ; 

Iterator*  anlterator  =  aList->getIterator ( ) ; 

//  For  each  item  in  the  iterator 
while (anIterator->moreData () )  { 

Schedule*  next Assignment  =  (Schedule*) 

(Entity* ) ( ( *anIterator) ( ) ) ; 

sscanf (nextAssignment ->Name ( ) , •%d' ,  &my_id) ; 

STEP*  the_step=f  ind_step (rny_id)  ; 
if (the_step->get_status ( ) ==3  &&  strcmp( 
the_step->get_designer ( ) , d_name)  !=0) { 
cout  <<  nextAssignment ->Name ( )  <<"\n“; 
int  T3=nextAssignment ->  AssignmentFinish ( ) -T1 ; 
cout  <<T3  <<"\n“; 

cout  <<  nextAssignment->AssignedDesigner ( )  <<  “\n“ 

) 

) 

delete  anlterator; 

CX:_transactionCommit  ( )  ; 

OC_close ( )  ; 


void  remove_step_f rom_schedule (char*  dbname.char* 
step_id, char*  myDate) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( )  ; 

deleteAssignmer.tl  ( “MySchedule" ,  step_id)  ; 

Time  T(nyDate) ; 

int  my_step_id,  an_id; 

sscanf (step_id, •%d* , &an_id) ; 

STEP*  the_step=find_step (an_id) ; 
char*  dname=the_step->get_designer ( ) ; 

Person*  aPerson= ( Person* )OC_lookup (dname) ; 
if(aPerson  !=  NULL) { 
aPerson->PersonStatus ( 0 ) ; 
aPerson->putObject ( ) ; 

} 

the_step->set_f inish_time (T) ; 
the_step->put Object ( ) ; 

Time  T2  =  the_step->get_start_time()+the_step- 
>get_estimated_duration ( ) ; 
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if ( (T2  -  T) ==0) 
couf.  <<  “N"  <<'\n*; 
else 

coat  <<"R"  <c*\n'; 

List  'dLisC  =  (List  • ) OC_lookup ( "MySchedule* ) ; 
if(aList  ==  NULL)  ( 

//  cout  <<  "No  Such  Schedule 

OC_transactionCotnmit  ( )  ; 

OC_close ( )  ; 
return; 

) 

Iterator*  aniterator  =  aList ->get Iterator () ; 

//  For  each  item  in  the  iterator 
while (aniterator- >moreData { 1 )  { 

Schedule*  next Assignment  =  (Schedule*) 

(Entity* ) ( ( * aniterator) ( ) ) ; 

sscanf  (nextAssignment ->Name ( )  .  •%d" ,  Simy_step_id)  ; 

STEP*  itiy_step  =  f  ind_step(my_step_id)  ; 
if(iny_step  !=  NULL)  ( 

List*  nTy_list  =  iny_step->preceded_by  ( )  ; 

Iterator*  my_Iterator  =  my_list->getIterator ( )  ; 
while(my_Iterator->moreData ( )  )  ( 

STEP*  a_srep=(STEP*) (Entity*) ( ( 'my.Iterator ' ( ) ) ; 
if  (a_step-j»get_step_id( )  s=  an_id) 
iny_step->set_in_degree(rny_step->get_in_degree  i )  - 

1)  ; 

my_step->putObject ( >  ; 

} 

) 

if  (iny_step->get_in_degree  ( )  ==0)  { 
if ( St rcmp(dname, nextAssignment - 
>AssignedDesigner ( ) ) ==0 ) { 

cout  <<  iny_step->get_step_id  ( )  <<*\n"; 
cout  <<  dname  <<"\n“; 

) 

else{ 

Person*  aPerson=  { Person* ) OC_loo)cup ( 

nextAssignment - >Ass ignedDes igner ( ) ) ; 
if(aPerson  !=  NULL) ( 

if (aPerson->PersonStatus ( ) ==0) { 
cout  <<  my_step->get_step_id  ( )  <<"\n''; 
cout  <<  nextAssignment - 
>AssignedDesigner ( ) << " \n* ; 

) 
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OC_transactionCommit ( ) ; 
OC_close ( ) ; 

) 


void  remove_step_f rom_sched ( int  step_id) 

( 

char  rny_id  ( 8  ]  ; 

sprintf  (my_id,  "%d" ,  st.ep_id)  ; 
int  my_step_id; 

deleteAss ignment  1  ( “MySchedule" ,  nT/_id)  ; 

STEP*  che_step=find_step(scep_id) ; 
if  (the_step  !=  NULL) { 
char*  dname=the_step->get_designer ( ) ; 
if (the_step->get_status ( )  ==  3){ 

Person*  a Persons (Person *)OC_lookup (dname) ; 
if(aPerson  !=  NULL) { 
aPerson->PersonStatus (0) ; 
aPerson->putObject ( ) ; 
cout  <<  step_id  <<  “in"; 
cout  <<  dname  <<  "\n"; 

} 

) 

List  *aList  =  (List  *) OC_loo)cup ( "MySchedule" )  ; 
if (aList  ==  NULL)  { 

//  cout  <<  "No  Such  Schedule  ...\n"; 
return; 

) 

Iterator*  aniterator  =  aList->getIterator ( ) ; 

//  For  each  item  in  the  iterator 
while {anIterator->moreData {) )  ( 

Schedule*  next Ass ignment  =  (Schedule*) 

(Entity* ) ( ( ‘aniterator ) ( ) ) ; 
sscanf ( next Ass ignment - >Name ( ) , "%d" ,  &my_  step_id) ; 

STEP*  my_step=f ind_step(my_step_id) ; 
if(my_step  !=  NULL) { 

List*  my_list  =  my_step->preceded_by ( ) ; 

Iterator*  my_Iterator  =  my_lisr-->getIterator(); 
while (my_Iterator->moreData {) )  ( 

STEP*  a_step= (STEP*) (Entity*) ( ( *my_Iterator ) ( ) ) 
if (a_step->get_step_id ( ) ==  step_id) 
my_st3p->set_in  degree (my_step->get_in_degree ( ) 


1)  ; 


) 

} 


iny_step->putObject  ( )  ; 

) 


void  suspend_abandon_step (char*  dbname, int  scep_id,  int 
new_status ) 

( 

OC_open ( dbname i ; 

OC_cransactionStart ( ) ; 

Time  T(0,0,0,0.0); 

STEP*  my_step=f ind_step(step_id) ; 
i£(my_step  !=  NULL) { 

if (my_step->get_status ( )  <=  1){ 
if (my_step->get_step_type( ) s=0) { 

List*  my_list=iny_step->3ubstep  ( )  ; 

List  Iterator  my._iterator  (my^list )  ; 
while (my_iterator .moreData ( ) ) { 

STEP*  a, .Steps  (STEP*)  (Entity*  ) rry_iterator  ( )  ; 
a_step->set_status {new_status) ; 
a_step->putObject ( ) ; 

) 

} 

my_step->set_status (new_status) ; 
my_step->putObject ( ) ; 

) 

else 

if  (iny_step->get_status  ( )  ==211  iny_step->get„status  ( ) 

=  =  3){ 

if  (my..step->get_step_type{ )  ==0)  { 

List*  iny_list=my.,step->substep ( )  ; 

Listiteratcr  my^iterator  (iny_list)  ; 
while (my_iterator .moreData { ) ) { 

STEP*  a_step= (STEP* ) (Entity* ) my_iterator ( ) 
remove_step_f rom_sched (a_step- 

>get_step_id{ ) ) ; 

a_step->set_3tatus (new^status) ; 
a_step->set_start_time (T) ; 

List*  a_list=a_step->preceded_by ( ) ; 
a_step->set_in_degree (a_list->Cardinality ( ) ) 
a_step->putObject  0 ; 

) 
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} 


my_step->set_status (new_scatus ) ; 
my_step->set_start_time (T) ; 
rny_step->putObject  ( )  ; 

) 

else{ 

remove_step_f rom_sched ( step_id) ; 
iny_step->set_status  (new_status )  ; 
tny_step->putObjecC  ( )  ; 

} 

} 

} 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 


void  show_steps (char*  dbname, char*  aName) 

{ 

OC_open (dbname) ; 

OC_transactionStart ( ) ; 

Set  'aSet  =  (Set  * )OC_lookup ( “step_set “ ) ; 

//  Abort  if  there  is  no  set 
if  (  aSet  ==  NULL  )  { 

cout  «  "there  is  no  steps  in  database  yet.\n*; 
return; 

} 

cout  «  aSet->Naine  ( )  <<  "  has  "  <<  aSet->Cardinality  ( )  <<  " 
items . \n\n" ; 

//  Ask  the  set  object  for  an  iterator 
Iterator*  aniterator  *  aSet->getItere.tor  ( )  ; 

//  For  each  item  in  the  iterator 
while (anIterator->moreData () )  { 

//  Get  the  item 

STEP*  the_step= (STEP*) (Entity  *) (aniterato. - 
>operator ( ) ( ) )  ; 

//  Print  out  its  name  and  value 
if (strcmp (aName, "ail  * ) ==0) 

cout  <<  the_step->get_step_id( )  <<  ",  Status:  " 

<<  Status  [the_step->get_stat:.us  ()]  <<  "\n"; 
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'\n' 


else( 

if (strcmp (aName, "top" ) =-  0) { 

i f ( the_step->get_step_type ( ) ==0 ) 
cout  <<  the_step->get_step_id { )  <<  ",  Status: 

<<  Status  tthe_step->get_status ( ) ] << 


) 

else 

if (strcmp (aName, Status [the_step- 
>get_status  0  1)  ==0 ) 

cout  <<  the_step->get_step_id { )  <<  ", 

Status:  * 

<<  Status [the_step->get_status ()] <<  "\n“ 

} 


) 


//Be  sure  to  cleanup  heap  based  iterators 
delete  aniterator; 

OC_transactionConiinit  ( )  ; 

OC^close ( )  ; 


► 


void  Add_primary_input (int  step_id, char*  thename) 

{ 

if(  thename[0]  !=‘0'){ 
char  coinp_naine  ( 64 ) ; 
int  var,  ver; 

sscanf  (thename,  "%s  %d:  %d* ,  coinp_nanie,  &var,  &ver)  ; 
STEP*  a_step=f ind_step(step_id) ; 
if (a_step  ! sNULL) { 

COMP_REFERENCE*  iry_ref=new  COMP_REFERENCE  ( )  ; 
iny_ref ->set_priv_name (comp_name)  ; 
nTv_ref ->set_version^no  (ver )  ; 
nv_ref->set_variation_no(var) ; 
my_ref->putObject { ) ; 
a_step->add_primary_input  (rny_ref )  ; 
a_step->putObject ( ) ; 

} 

else 

cout  <<"STEP:  *  «  step_id  «'  is  not  in  the 

DDB\n" ; 

} 


) 


void  Delete_primary_input  (int  step_id,  char*  coinp_name) 

{ 
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i  f  (  coinp_name  (01  !  =  ‘  0  • )  { 

STEP*  a_step=f ind_step (step_id) ; 
if(a_step  !=NULL){ 

a_step->delete_primary_inpuc  ( coinp_nani'= ) 
a_step->putObject ( )  ; 

) 

} 

} 

void  Add_secondary_input  (int  step_id,char  *Chenanie) 

{ 

if(  thename(0]  !=*0‘){ 
char  coinp_name  (641; 
int  var,  ver; 

sscanf  (thename,  "%s  %d:  %d“ ,  coinp_name,  Sivar,  &ver)  ; 
STEP*  a_step=find_step(step_id) ; 
if(a_step  !=NULL){ 

COMP_REFERENCE*  iny_ref=new  COMP_REFERENCE ( ) ; 
my_ref - >set  _pri v_name ( comp_name ) ; 
ity_ref->set_version_no(ver)  ; 
iny_ref->set«variation_no  (var)  ; 
nty^ref->putObject  ( )  ; 

a_step->add_secondary_input (my^ref ) ; 
a^step->putObject ( ) ; 

} 

else 

cout  «''STEP:  •  «  step^id  «“  is  not  in  the 


DDBXn" ; 

} 


} 


void  Delete^secondary^input (int  step^id, char*  comp_naine) 

{ 

i  f  (  coinp_name  ( 0  ]  !  = '  0  ' )  { 

STEP*  a_step®f ind_step{step_id) ; 
if(a_step  ! sNULL) { 

a_step->delete_secondary_input (comp_name) ; 
a_step->putObject ( ) ; 

) 

) 

} 


void  Add_af  fected_inodules  (int  step_id,  char*  thename) 

{ 

if(  thename [0]  !=’0'){ 
char  comp^name [ 64 ] ; 
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int  var,  ver; 

sscanf  (thename.  “%s  %d;  %d“ ,  comp_naine,  S.var,  &ver)  ; 
STEP*  a_step=f ind_step{step_id) ; 
if(a_step  ! =NULL) ( 

COMP_REFERENCE*  iny_ref=new  COMP_REFERENCE(); 
my^ref ->set_pri  v_naine  ( conip_name)  ; 
rny_ref->set_version_no (ver )  ; 
iry_ref ->set_variation_no(var)  ; 
my_ref ->putObject ( ) ; 

a_step->add_af  fected_modules  (iny_ref )  ; 
a_step->putObject ( )  ; 

) 

else 

cout  <<*STEP:  *  <<  step_id  <<“  is  not  in  the 


DDB\n*; 

} 

} 

void  Delete_af  fected_modules  (int  step_id,  char*  coinp_naine) 

{ 

if(  comp_name ( 0 1  !*'0*){ 

STEP*  a_step=find_step(step_id) ; 
if(a_step  ! sNULL) { 

a_step->delete_af fected_modules (comp^name) ; 
a_step->putObject ( ) ; 

} 

} 


) 


void  Update_precedence(int  st6p_id, int  preceding_step_id) 
{ 

OC_Boolean  FOUND  *  FALSE; 
if (preceding_step_id  !=0){ 

STEP*  a_step=find_step(step_id) ; 
if(a_step  !=NULL){ 

STEP*  the_step*f ind_step (preceding_step_id) ; 
if (the_step) { 

List*  the_list=  a_step->preceded_by ( ) ; 

Listiterator  the_iterator (the_list ) ; 
while (the_iterator .moreData ( ) ) 

( 

STEP*  stepl= (STEP*) (Entity* ) the_iterator ( ) ; 
if  (stepl->get_step_id( ) ==  preceding_step_id) 
FOUND  =  TRUE; 

} 

if ( (FOUND) { 
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a_step->add_predecessor (the_step) ; 
a_step->putObject ( ) ; 

if (the_step->get_step_Cype ( ) ==0  &&  a_step- 
>get_step_type( ) ==0) { 

COMP_REFERENCE*  iny_ref =the_step->get_base_version ( ) ; 
COMP_REFERENCE*  rny_ref l=a_step->get_base_version ( ) ; 
if  ( strcmp  (iny_ref ->get _j)riv_name  { )  ,  my_ref  1- 
>get^riv_name  ( )  )  ==0  && 

iny_ref->get_variation_no( )  ==  my^refl- 
>get_variation_no ( )  && 

iiiy_ref ->get_version_no  ( )  ==  iny_ref  1  - 
>get_version_no ( ) ) { 

List*  iny_list  =  the_step->substep  { )  ; 

Listiterator  iny_iterator  (rny_list )  ; 
while (my_iterator .moreData { ) ) 

{ 

STEP*  rny_step=  (STEP*)  (Entity* ) iny_iterator ()  ; 

List*  a_list  =  nty_step->priinary_input  ( )  ; 
COMP_REFERENCE*  a_ref=  (COMP_REFERENCE* ) a_list - 
>getEntityElement ( 0) ; 

cout  <<• first:  *<<  a_ref->get_priv_name ( )  <<  "\n"; 

List*  iny_listl  =  a_step->substep  ( )  ; 

Listiterator  iny_iteratorl  (my_listl )  ; 
while  (iny_iteratorl  .moreData  { ) )  { 

STEP*  nTy_stepl=(STEP*)  (Entity*  )iny_iteratorl  ( )  ; 
List*  a^listl  *  nTy_stepl->primary_input  ( )  ; 
COMP_REFERENCE*  a_refl=  (COMP_REFERENCE* ) a_listl- 
>getEntityElement (0) ; 

cout  <<’second:  “<<  a_ref l->get_priv_name ( )  <<  "\n"; 
if ( strcmp (a_ref->get_priv_name( ) ,  a_refl- 
>get_priv_name ( ) ) ==0 ) { 

my_stepl->add_predecessor  (iny_step)  ; 
iny_stepl->putObject  ( )  ; 

} 

} 

} 

} 

} 

} 

) 

else 

cout  «"STEP:  ’«  preceding_step_id<< "  is  not  in 

the  DDBXn"; 

} 

else 

cout  <<*STEP:  "  <<  step_id  <<"  is  not 
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in  the  DDBVn"; 

) 

) 


void  Update_priority ( int  step_id, int  value) 


{ 


if (value  !=0) { 

STEP*  a_step=f ind_step(step_id) ; 
i f ( a_step  ! =NULL) { 

a_3tep->set_priority (value) ; 
a_step->putObject { ) ; 


} 

else 


in  the  DDB\n“; 

) 

} 


cout  «“STEP:  *  <<  step^id  <<“  is  not 


void  Update_expertise_level (int  step_id, int  value) 


{ 


if (value  ! *5) { 

STEP*  a_step=f ind^step (step_id) ; 
if(a_step  !=NULL){ 

a_step->set_required_expertise_level (value) 
a_step->putObject { ) ; 

} 

else 

cout  <<"STEP:  ■  «  step_id  <<•  is  not  in  the 


DDB\n* ; 
} 


} 


void  Update_status (char*  dbnaine,int  step_id, int  value) 

{ 

(X^open  ( dbname ) ; 

OC^transactionStart ( ) ; 

STEP*  a_step=f ind_step (step_id) ; 
if(a_step  !=NULL){ 

a_step->set_status (value) ; 
a_step->put Object ( ) ; 
if  (value  *=211  value  ==  3){ 

STEP*  iny_step=  a_step->get_parent_step  ( ) 
if  (iny_step!=  NULL)  { 

if  (iny^step->get_status  ( )  <  value)  { 
iny_step->set_status  (value)  ; 
iny_step->putObject  ( )  ; 


) 

) 

} 

) 

else 

cout  <<"STEP:  *  <<  step_id  <<"  is  not  in  the 

DDB\n" ; 

OC_transactionConin\it  ( )  ; 

OC_close ( )  ; 

) 


void  Update_deadline ( int  step_id, char*  theDate) 

{ 

if {theDate(01  !=0  &&  theDate[l)  !=0){ 

STEP*  a_step=f ind_step ( step_id) ; 
if(a_step  !=NULL){ 

Time  theTime(theDate); 
a_step->set_deadline ( theTime) ; 
a_step->putObject ( )  ; 

List*  my^list  =  a_step->substep { ) ; 

Listiterator  an_iterator (my.list) ; 
while (an_iterator. moreData ( ) ) 

{ 

STEP*  iny_step=(STEP*'  (Entity*  )  an_iterator  ( )  ; 
iny_step->set_deadline (theTime)  ; 
my_step->putObject ( ) ; 

} 

} 

else 

cout  <<"STEP:  *  «  step_id  «"  is  not  in  the 

DDBNn* ; 

} 


void  Update^deadline (char*  dbname.int  step_id) 

{ 

OC_open ( dbname ) ; 

CX:_transactionStart ( ) ; 

OC_Boolean  FOUND=FALSE; 
char  an_id[8]; 

Time  T(0,0,0,0,0) ; 
sprintf (an_id, *%d" , step_id) ; 

STEP*  a_step=find_sten(step_id) ; 
if(a_step  !=NULL){ 

List  *aList  =  (List  * )OC_lookup ( "MySchedule" ) ; 
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ifOList  !=  NULL)  { 

Iterator*  niy_iterator  =  aList->getIterator  ( )  ; 

//  For  each  item  in  the  iterator 

while (my_iterator->moreData () &&  ! FOUND)  { 

Schedule*  nextAssignment  =  (Schedule*) 

( Entity* ) { ( *my_iterator)  ( ) ) ; 

if(  strcmp (n3xtAssignment->Name ( ) , an_id) ==0  ){ 
FOUND  =  TRUE; 

T  =  nextAssignment->AssignmentFinish ( ) ; 

) 

) 

STEP*  the_step=a_step->get_parent_step ( ) ; 
the_step->set_deadline (T) ; 
the_step->putObject ( ) ; 

List*  iny_list  =  the_step->substep  ( )  ; 
Listiterator  an_iterator  {iny_list)  ; 
while {an_iterator .moreData ( ) ) 

{ 

STEP*  my_step={STEP*) (Entity* ) an_iterator ( ) ; 
iny_step->set_deadline (T)  ; 
tny^step->putObj€Ct  ( )  ; 

} 

} 

) 

OC_transactionCommit ( ) ; 

OC^close ( ) ; 

} 


void  Update_estiniated_duration(int  step_id,int  value) 

{ 

OC.Boolean  FOUND=FALSE; 
char  an_id(8J; 
if (value  !=0) { 

sprintf (an_id, •%d" , step^id) ; 

STEP*  a_step*f ind_step (step_id) ; 
if(a_step  !=NULL){ 

if (a_step->get_status ( ) ==3) { 

int  n  =  value  -  a_step->get_estimated_duration ( ) 
List  *aList  =  (List  *)OC_loo)cup(  "MySchedule" )  ; 
if(aList  !=  NULL)  { 

Iterator*  iny_iterator  *  aList->getIterator ( ) ; 

//  For  each  item  in  the  iterator 

while  (iny_iterator->moreData  {)  St  &  (FOUND)  { 

Schedule*  nextAssignment  =  (Schedule*) 

(Entity*)  ( ( *iny_iterator)  ()); 


if(  strcmp  {nextAssigninent->Naine  ( )  ,  an_id)  =  =  0  ){ 

FOUND  =  TRUE; 

next  As  signinent->  Assignment  Finish  (next  Assignment  - 
>AssignmentFinish  ( )  •►n)  ; 

nextAssignment->putObject ( ) ; 

} 

) 

} 

} 

a_step->set_estimated_durat ion (value) ; 
a_step->putObject ( ) ; 

} 

else 

cout  <<*STEP:  *  <<  step_id  <<“  is  not  in  the  DDB\n“ ; 

} 

) 

void  Update_start_time (char*  dbname, int  step_id, char* 
theDate) 

{ 

OC_open (dbname) ; 

OC_transactionStart { ) ; 

Time  T{0,0,0,0,0) ; 

STEP*  a_step=f ind_step (step_id) ; 
if(a_step  !=NULL){ 

Time  theTime ( theDate ) ; 
a_step->set_start_time(theTime) ; 
a_step->putObject ( ) ; 

STEP*  the_step=a_step->get_parent_step ( ) ; 
if (strcmp{the_step- 
>get_start_time  ( )  .malceString  ( )  , 

T.ma)teString  ( )  )  ==0)  ( 
the_step->set_start_t ime ( theTime ) ; 
cout  «  "done*  «  "\n"; 
the_step->putObject ( ) ; 

} 

} 

else 

cout  <<"STEP:  "  <<  step_id  <<"  is  not  in  the 

DDB\n" ; 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 

} 

void  Update_f ini sh_t ime (char*  dbname, int  step_id, char* 
theDate) 
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{ 


OC_open ( dbname ) ; 

OC_transactionStart ( )  ; 

STEP*  a_step=f ind_step(step_id) ; 
if(a_step  ! =NULL) { 

Time  theTime (theDate) ; 
a_step->set_f inish_time ( theTime) ; 
a_step->putObject ( ) ; 

STEP*  the_step=a_step->get_parent_step ( ) ; 
if (theTime  >  the_step->get_f inish_time ( ) ) { 
the_st ep->set^f ini sh_t ime ( theTime ) ; 
the_step->putObject ( ) ; 

} 

} 

else 

cout  <<'‘STEP:  ■  <<  step_id  <<*  is  not  in  the 

DDB\n" ; 

OC_transactionCommit ( ) ; 

OC_close ( )  ; 

} 

void  Update_designer (char*  dbname, in t  step_id, char*  aName) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( ) ; 

STEP*  a_step=find_step(step_id) ; 
if(a_step  1=NULL){ 

a_step->set_designer (aName) ; 
a_step->putObject ( ) ; 

} 

else 

cout  «“STEP:  "  «  step_id  <<•  is  not  in  the 

DDB\n“ ; 

OC_transactionConimit  ( )  ; 

OC_close( )  ; 

} 

void  Update_Step (char*  dbname, int  step_id, char*  theDate, 

char*  p_inputA,  char*  p_inputD, 
char*  s_inputA,  char*  s_inputD, 
char*  a_inputA,  char*  a_inputD, 
int  pri_value,  int  prec_vlaue, 
int  dur_vlaue,  int  exp_levvel) 

{ 

OC_open (dbname) ; 

OC_transactionStart ( )  ; 
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STEP*  a_scep=f ind_step (st2p_id) ; 
if(a_step  !=NULL){ 

if {a_step->get_status ( ) <=  1){ 

step_updace { step_id, theDace, p^inputA, p_inputD, s_inputA, s_inp 
utD, 

a_inputA, a_inputD, pri_value, prec_vlaue, dur_vlaue, exp_levvel ) 

» 

a_step->putObject ( ) ; 
cout  <<  “d"  <<*\n*; 

) 

else 

if (a_step->get_status ( ) ==  2  II  a_step- 
>get_stacus ( ) ==  3) 

{ 

//  save_step_old_values (a_step) ; 

step_update ( step_id, theDate,p_inputA,p_inputD, s_inputA, s_inp 
UtD, 

a_inputA,  a_inputD,  pri_value,  prec^vlaue,  dur^vlaue,  exp_lewel ) 

# 

cout  «  *s*  «“\n*; 
a_step->put0b3ect ( ) ; 

} 

else 

if (a_step->get_status ( ) ==  4) 
cout  «  *c"  <<*\n"; 
else 

if (a_step->get_status ( ) ==  5) 
cout  «  *a*  «'\n’; 


) 

OC^transactionCommit ( ) ; 

OC_close( ) ; 

} 

void  step_update ( int  step_id, char*  theDate, 

char*  p_inputA,  char*  p_inputD, 
char*  s_inputA,  char*  s_inputD, 
char*  a_inputA,  char*  a_inputD, 
int  pri_value,  int  prec_vlaue, 
int  dur_vlaue,  int  exp_level) 


{ 


Update_deadline (step_id, theDate) ; 


Add_priinary_input  {step_id,  p_inputA)  ; 
Delete_primary_input (step_id,  p_inputD) ; 
Add_secondary_input (step_id, s_inputA) ; 
Delete_secondary_input (step_id, s_inpucD) ; 

Add_af  f ected_modules ( step_id, a_input A) ; 
Delete^af  f ecced_modules ( step_id, a_inputD) ; 
Update_prioricy (step_id, pri_vaiue) ; 

Update_precedence ( step_id, prec_vlaue) ; 
Update_estimated_duration {step_id, dur_vlaue) 
L,'pdate_expeL-tise_level  (step_id,  exp_level )  ; 

) 

void  save_step_old_values (STEP*  a_step) 

{ 

STEP*  temp_step=  new  STEP ( * temp_scep* , 0 ) ; 
teinp_step->primary_input  (a_step->primary_input  { )  )  ; 
temp_step->secondary_input (a_step->secondary_input ( ) ) 
t  emp_s  tep->affecc  ed_modu le(a_step- 
>af fected_module { ) ) ; 

temp_step->set_priority (a_step->get_priority ( ) ) ; 
temp_step->preceded_by (a_step->preceded_by ( ) ) ; 
temp_step->set_estimated_duration(a_step- 
>get_estimated_duration ( ) ) ; 

temp_step->set_deadline(a_step->get_deadline() > ; 
t emp_s t  ep - >set_requi red^exper t i s  e_l eve 1 ( a_s  c  ep - 


void  Undoes tep_update (char*  dbname, int  step_id) 

( 

OC^open ( dbname ) ; 

OC_transactionStarC ( ) ; 

STEP*  a_step=f ind_step(step_id) ; 
if (a_step) { 

STEP*  teinp_stepa  {STEP*)OC_lookup(  *temp_step* )  ; 
if (temp_step) { 

a_step->primary_input (temp_step->primary_input ( ) ) 
a_step->secondary_input ( temp_step- 
>secondary_input () ) ; 

a_step->af fected^module ( temp_step- 
>affected_module( ) ) ; 

a_step->set_priority {temp_step- 
>get_priority ( ) ) ; 

a_step->preceded_by (temp_step->preceded_by ( ) ) 
a_step->set_estimated_duration (temp_step- 


>get_est imated_durac ion ( ) )  ; 

a_step->set_deadl ine (temp_step- 
>get_deadline ( ) ) ; 

a_step- 

>set_required_experc ise_level ( temp_step- 
>get_required_expert ise_level ( ) ) ; 

temp_step->deleteObject ( )  ; 
a_step->putObject { )  ; 

) 


} 

OC_cransactionCommit ( ) ; 

OC_closG { ) ; 

) 

void  credce_step (char*  dbname.  char*  pr_Naiiie,  char* 
comp_name ) 

{ 

OC_open ( dbname ) ; 

0C_transaction5;tart  ( )  ; 

int  itiy_step_id=0  ; 

int  var.  ver,  varl.verl; 

char  protoName(64] ; 

char*  iny_step_name=*step_*  ; 

char  theName ( 64 1 ; 

char  temp[64); 

Set  *aSct  =  (Set  • )OC_lookup ( "step_set “ )  ; 

//  If  it  does  not  exist,  create  it 
if(aSet  ==  NULL)  { 

//cout  <<  “Creating  set  object  ...\n“; 


//  Create  a  new  set  called  stsp_set 

aSet  =  new  Set  (  (Type*) OC_loo)cup(  “STEP* )  ,  “step_set“) 
} 

//  Create  step  objects  and  insert  it  into  the  step_set 
Sequencer* 

aSequencer=  ( Sequencer*  )OC_loo)cup(  “Step_Sequencer“ )  ; 
if (aSequencer-=  NULL) { 

//cout  <<  “Creating  Sequencer  object  ...\n“; 
aSequencer=  new  Sequencer (" St ep_Sequencer“ ) ; 

//  aSequencer->putObject ( ) ; 

iny_step_id=l  ; 

} 

else{ 

//  cout  <<  aSequencer->Name ( )  <<  “  already  exists. \n 

iny_step_id  =  aSequencer->getValue(); 
aSequencer->putObject ( )  ; 


// 


sprint f  (temp,  “%s%d“ ,  iny_step_name, my_step_icl)  ; 

STEP*  a_step=new  STEP(temp.nTy_step_id)  ; 

sscanf (pr_Name. "%s  %d: %d" , theName,  &var,  &ver) ; 

char  *aName  =  new  char (strlen ( theName) +1 ] ; 

strcpy (aName, theName) ; 

if(var==0)  varl  =  1; 

else  varl  =var; 

if(ver==OI  verl  =1; 

else  verl=ver; 

sprintf  (protoName,  *%s  %d:  %d‘‘ ,  aName,  varl,  verl); 
thepath=0; 

f ind_component_pcth (protoName, aName) ; 
if ( Ithepath) { 

cout  <<  “there  is  no:  *<<aName  <<“  prototype  in  DDB 

\n*; 

return; 

) 

else{ 

COMP_REFERFNCE*  nTy_ref=new  COMP_REFERENCE  ( )  ; 
my_ref->set_priv_name (aName) ; 
niy_ref->set_version_no(ver)  ; 
ny_ref->set_variation_no(var) ; 
my_ref->put0b3ect { ) ; 
a_step->set_base_version {iTiy_ref )  ; 

sscanf (comp_name, “%s  %d: %d" , theName,  &var,  &ver); 

char*  a_name=new  char [strlen( theName) +1) ; 
s  t  rcpy ( a_name , theName ) ; 
char*  check=0; 

chec)c  =  theName-t-strlen(theName) -10; 
if ( St rcmp (check, * .spec.psdl* ) ==0) { 

My_String  templ=  l^_String (theName) -10 ; 
char*  checkl=:(char*)tenpl; 
find_component_path( protoName, checkl) ; 
if ( ! thepath) 

cout  <<“ there  is  no:  •<<theName  <<"  component 

in  DDB  \n“; 

else( 

COMP_REFERENCE*  my_ref=new  COMP_REFERENCE ( ) ; 
my_ref->set_priv_name<a_name) ; 
iny_ref->set_version_no  ( ver)  ; 
my_ref->set_variation_no (var) ; 
my_ref->putObject ( ) ; 

set_af f ected_modules (a_step,  protoName, checkl ) ; 
a_step->add_primary_input  (iny_ref )  ; 
aSequencer->putObject ( )  ; 
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a_step->putObject ( ) ; 
aSet->Insert (a_step) ; 
aSet->putObject ( ) ; 

) 

}else{ 

char*  checkl  =0; 

checkl  =  theName+strlen ( theName) -9 ; 
if ( St rcmp (checkl, * . imp.psdl* ) ==0) { 

My_String  teinpl=  My_,String(theName) -9; 
char*  checkl= (char*) tempi; 

f ind_component_path(protoName, checkl ) ; 
if ( ! thepath) 

cout  <<■ there  is  no:  "<<theName  <<*  component 

in  DDB  \n“; 

else{ 

COMP_REFERENCE*  my_ref=new  COMP_REFERENCE ( ) ; 
nty_r‘ef->set_priv_name  (a_name)  ; 
iny_ref ->set_version_no  (ver)  ; 
nTy_ref->set_variation_no(var)  ; 
niy_ref->putObject  ( )  ; 
a_scep->add_primary^input  (rry^ref )  ; 
aSequencer->putObject ( ) ; 

set_secondary_input (a_step, thepath) ; 
strcat (checkl, ■ .spec.psdl') ; 
my.refsnew  COMP_REFERENCE ( ) ; 
iny_ref->set_priv_name  (checkl)  ; 
my_ref->putObject ( )  ; 
a_step->add_secondary_input  (iny_ref )  ; 
a_step->putObject ( ) ; 
aSet->Insert (a_step) ; 
aSet->putObject ( ) ; 

} 

}else 

cout  «  "wrong  components  suffix  \n“; 

} 

} 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 

} 

void  set_af fected_modules (STEP*  a_step,  char*  protoName, char* 
comp_name) 

{ 

char*  aName=  new  char(strlen(comp_name)+l]; 
scrcpy (aName, comp_name) ; 
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COMP_REFERENCE*  itiy_ref=new  COMP_REFERENCE  ( )  ; 
char  temp [64]; 

sscanf  {protoName,  ■‘%s“,  temp)  ; 
if  (strcmp (temp. comp_name) ! =0) { 
char  •separators".*; 
char*  word[51; 
int  i*0; 

word[0] astrtok(comp_name.  separator) ; 
while{word(i]  !=NULL){ 
i=i+l; 

word(i]  =strto)c(NULL.  separator); 

} 

int  n  =  strlen (word(i-l] ) +1 ; 

My_String  temp=My_String (aName) -  n 
+My —String ( " . imp . psdl * ) ; 

char*  parents (char*) temp; 

my^ref->set_priv_name (parent) ; 
ny_ref ->putObject ( ) ; 
a_step->add_af fected_modules (my^ref ) ; 

} 

street (aName, • .imp. psdl") ; 
my_ref=new  COMP_REFERENCE ( ) ; 
rny_ref->setjpriv_name(aName)  ; 
iny_ref ->putObject  ( )  ; 
a_step->add_af fected_modules (my_ref ) ; 
a-Step->putObject ( ) ; 


void  set_secondari'_input  (STEP*  a_step,char*  compPath) 

{ 

COMP_REFERENCE*  my_ref; 
char  *  checks ( char* ) 0 ; 

COMPONENT  *ny_comp  = (COMPONENT  *) OC_lookup (compPath) ; 
if(my_comp  !=  NULL) { 

List*  iry_list  »  iny_comp->subComponents  ( )  ; 

Listiterator  my_iterator (my_list) ; 

COMPONENT  *theComponent ; 
while (my_iterator .moreData ( ) ) 

{ 

theComponents (COMPONENT  *) (Entity* )ny_iterator ( ) ; 

List*  the_list  =  theComponent->TextObjectList ( ) ; 
Listiterator  the_iterator (the_list) ; 

TEXT_OBJECT  *  t  he_t  ext_ob j  ec  t ; 
while ( the_i terator. moreData ( ) ) 

{ 

the_text  ..object  = 


/ 
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(TEXT_OBJECT*) ( Entity *) the_iterator ( ) ; 

check  =the_text_object->getFileNanie  ( ) 

strlen (the_text^object->getFileName ( ) ) -10 ; 
if ( St rcmp (check, * . spec .psdl" ) ==0) { 
iny_ref=new  COMP_REFERENCE  ( )  ; 
jny_ref  -  >set  jri  v^name  ( the_t  ext_ob  j  ect  - 
>getFileName ( ) ) ; 

iny_ref->putObject  ( )  ; 
a_step->add_secondary_inpat  (nty_ref )  ; 

} 

} 

) 

} 

else 

cout  «"cannot  find  the  component  \n"; 

} 


void  create_substep (char*  dbname.int  step_id,  char*  p_input, 

char*  d_name,  char*  thedate,  int 

duration) 

{ 

OC_open (dbname) ; 

OC_transactionStart ( ) ; 

OC.Boolean  FOUND=FALSE; 

Time  T1 (thedate) ; 

int  my_step_id=0; 

char  temp [64]; 

char  tempi [64]; 

char*  my_s t ep_name  =  * s t ep_ * ; 

Set  *aSet  =  (Set  * )OC_lookup { “step_set • ) ; 

Sequencer* 

aSequencer=( Sequencer* )OC_lookup( "Step^Sequencer" ) ; 
iny_step_id  =  aSequencer->getValue(); 
aSequencer->put Object ( ) ; 

sprintf (temp, "%s%d" ,  ny_step_name, step^id) ; 

STEP*  the_step= (STEP* ;OC_lookup  (temp) ; 
if  (the_step  ==  NULL) 

cout  <<* there  is  no  such  parent  step  \n"; 
else{ 

sprintf (tempi, "%s%d" ,  my_step_name,my_step_id) ; 

STEP*  a_step=new  STEP ( tempi, my_step_id) ; 
if (p_input [0] !=  '0'){ 

COMP_REFERENCE*  my_ref=new  COMP_REFERENCE ( ) ; 
iny_ref->set _priv_name (p_input)  ; 
my_ref->putObject ( ) ; 
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a_step->addjpriinary_input  (niy_ref )  ; 
a_step->set_parent_step (the^step) ; 

a_step->set_base_version (the_step->get_base_version ( ) ) ; 
a_step->set_deadline(the_step->get_deadline{ ) ) ; 
a_step->set_priority {the_step->get_priority ( ) ) ; 
a_s  t  ep - >s  et_es  t ima  t  ed_du  ra t ion ( du  ra  t i on ) ; 
a^step->set_step_cype (5) ; 

List*  iny_list=  the_step->substep  I ) ; 

Listiterator  iny_Iterator  (iny_list)  ; 

STEP*  nTy_step; 

//  For  each  item  in  the  iterator 
while  (iny_Iterator  .moreData  ()  &&  !  FOUND)  { 

//  Get  the  item 

my _step=  (STEP* )  (Entity  *)nTy_Iterator  ( )  ; 
if (my_step->get_status ( ) ==3  && 

strcmp(nv_step->get_designer() ,d_name)==0) { 
a_step->add_predecessor (my^step) ; 

FOUND  *  TRUE; 

) 

> 

a_step->putObject ( ) ; 

cout  «  a_step->get_step_id ( ) «  "\n*; 
int  T2=  a_step->get_deadline( )  -  Tl; 
if  (T2  <  0) 

cout  «*1000*  «  "Nn"; 
else 

cout  «T2  <<  "Nn"; 

cout  «a_step->get_priority  ( )  «  ’\n"; 

cout  «a_step->get_estimated_duration  ( )  «"\n'; 

cout  « " { •  ; 

a_step->show_preceding_steps ( ) ; 
cout  «■]  \n“ ; 
cout  «Level  [a_step- 
>get_required_expertise_level { ) ] «  • \n" ; 

cout  «  a_step->get_in_degree ( )  «  "\n‘; 

thi;_step->add_substep  (a_step)  ; 
char  protoname [64] ; 

My_String  temp4=  My_String(p_input) -9; 
char  *compname  =  (char*)  temp4; 

COMP_REFERENCE*  ity_comp=  the_step->get_base_version  ( )  ; 

char  *temp2=iny_comp->get_priv_name  ( )  ; 

int  var=my_comp->get_variation_no ( ) ; 

int  ver=iry_comp->get_version_no  ( )  ; 

sprint f (protoname, "%s  %d:%d*,  temp2,var,  ver) ; 
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f ind_component_path (protoname,  compname) ; 
if  (thepath) 

set_secondary_input (a_step, thepath) ; 

//  else 

//  cout  <<''Cannot  find  component:  *  <<  compname  <<"  in 

DDB  \n“; 

} 

the_step->putObject ( ) ; 
aSet->Insert (a_step) ; 
aSet->putObject ( ) ; 

} 

OC_transactionCommit ( ) ; 

OC_close( ) ; 

} 


STEP*  create_substep (STEP*  the_step,  char*  p_input) 

{ 

/ /  OC_open { dbname ) ; 

I i  OC_transactionStart ( ) ; 
int  my_step_id=0; 
char  tempi [64]; 
char*  rny_s t ep_name  =  *  s t  ep_ “  ; 

Set  *aSet  =  (Set  *)OC_lookup( "step^set* ) ; 

Sequencer* 

aSequencer=  < Sequencer *)OC_lookup{ "St ep^Sequencer" ) ; 
ny— step^id  =  aSequencer->getValue( ) ; 
aSequencer->putObject ( ) ; 

sprint f (tempi, "%s%d",  ny_step_name,my_step_id) ; 

STEP*  a_step=new  STEP(tenpl,my_step_id) ; 

//  cout  «"step  name:  "  «templ  «"\n"; 

COMP_REFERENCE*  my_ref =new  COMP_REFERENCE ( ) ; 
char*  a_name=0; 

a_name=new  char [strlen {p_input ) +1 1 ; 
strcpy { a_name , p_input ) ; 
nty_ref->set_priv_name (a^name) ; 
my_ref->putObject ( ) ; 

a_step->set_base_version (the_step->gat_base_version ( ) ) ; 

a_step->add_primary_input  (iny„ref )  ; 

a_step->set_parent_step(the_step) ; 

a_step->putObject ( ) ; 

the_step->add_substep (a_step) ; 

char  protoname [64] ; 

My_String  temp4=  My_String (p_input ) -9 ; 
char  *compname  =  (char*)  temp4; 

COMP_REFERENCE*  my_comp=  the_step->get_base_version ( ) ; 
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char  *temp2=nv_comp->get_priv_name ( ) ; 

int  var=iny_comp->get_variation_no  { )  ; 

int  ver=nv_coinp->get_version_no  { )  ; 

spr int f (protoname, *%s  %d:%d*.  temp2,var,  ver) ; 

char*  check=a_name+strlen(a_name) -10; 

if (strcmp{ check, * .spec. psdl*)  !=  0) 

{ 

thepath  =0; 

find_component_path( protoname,  compname) ; 
if  (thepath) { 

//  cout  <<" check:  *  «check  <<*\n“; 

set_secondary_input (a_step. thepath) ; 
strcat (compname, * . spec. psdl * ) ; 

COMP_REFERENCE*  my_ref=new  COMP_REFERENCE(); 
my_ref->set_priv_name( compname) ; 
my_ref->putObject ( ) ; 
a_step->add_secondary_input (my_ref ) ; 

else 

cout  « “Cannot  find  component:  “  <<  compname  <<*  in 

DDE  \n“; 

} 

a_step->putObject ( ) ; 
the_step->putObject ( ) ; 
aSet->Insert (a_step) ; 
aSet->putObject ( ) ; 
return  a_step; 


void  auto_create_substeps (char*  dbname,int  step_id) 

{ 

OC_open(dbname) ; 

OC_transactionStart ( ) ; 

COMP_REFERENCE*  iny_ref; 

STEP*  ny_step; 

STEP*  a_3tepl; 

STEP*  a_step2; 

char  temp (64 J; 

char*  rny_s t ep_name  = "  s t  ep_ "  ; 

sprintf (temp, “%s%d" ,  my_step_name, step_id) ; 

STEP*  the_stepa (STEP*)OC_lookup  (temp); 
if  (the_step  =*  NULL) 

cout  «“there  is  no  such  parent  step  \n“; 
else{ 

List  *iny_list=the_step->primary_input  ( )  ; 

my_ref  = (COMP_REFERENCE* )my_list->getEntityElement { 0 ) ; 
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//  char*  iny_name=0; 

int  nl=  strlen{nTy_ref->get_priv_name( )  ) +1; 
char*  iny_name=new  char(nll; 
strcpy  (my_naine,  rny_ref->get_j>riv_naine  ( ) )  ; 
iny_name  ( nl  ]  =  '  \  0  *  ; 

rny_step=  create_substep (the_step,iny_name)  ; 

//  cout  << “iny_nanie :  ■  «rny_name  <<“\n“; 

char*  check=0; 

check  =  niy_ref->get_priv_name  ( ) -t-strlen  (niy_ref- 
>get_priv__name  ( )  )  -10  ; 

//  cout«“ check:  •  <<  check  «"\n“; 

if (strcmp( check, * .spec.psdl* ) ==0) { 
iny_step->set_step_type(l)  ; 
iny_step->set_status  (1)  ; 

iny_step->set_deadline{the_step->get_deadline( )  )  ; 
my_step->set_priority (the_step->get_priority ( ) ) ; 
the_step->set_status ( 1 ) ; 
the_step->putObject ( ) ; 
iny_step->putObject  ( )  ; 

List*  a_list  =  the_step->af  f  ected_inodule  { )  ; 
COMP_REFERENCE*  a_ref 1 ; 

COMP_REFERENCE*  a_ref2; 

a_re  f 1  = ( COMP_REFERENCE  * ) a_l i s  t - 
>getEntityElement (0) ; 

//  char*  a_naine2=0; 

int  n2*strlen  (a_ref  l->get_priv_naine  ( )  )  +1  ; 
char*  a_name2=  new  charln2]; 
strcpy  (a_naine2, a_ref l->get_priv_name  ( )  )  ; 
a_naine2  [n2 ]  =  '  \0  • ; 

//  cout  «"iny_name:  "  «a_name2  «"\n“; 

a_stepl  =  create_substep{the_step,a_naine2)  ; 
if (a_list->Cardinality ( ) ==1) 
a_stepl->set_step_type(2) ; 
else 

a^stepl->set_step_type(3) ; 
a_stepl->set_status (1) ; 

a_stepl->add_predecessor (my_step) ; 
a_stepl->set_deadline{the_step->get_deadline ( ) ) ; 
a_stepl->set_priority (the_step->get_priority ( ) ) ; 

a_stepl->putObject ( ) ; 
if (a_list->Cardinality ( ) >  1){ 

a_ref2  = (COMP_REFERENCE* ) a_list- 
>getEntityEleinent  (1)  ; 

int  n3=strlen(a_ref2->get_priv_naine( )  )+l; 
char*  a_namel=  new  char[n3]; 

//  cout  «'‘iny_naine:  *  «a_nainel  «"\n"; 
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strcpy (a_namel,a_ref2->get_priv_name( ) ) ; 
a_namel (n3 ] = ‘ \0 ‘ ; 

a_step2  a  create_substep ( the_step, a_namel ) ; 
a_step2->set_step_type(2) ; 
a_step2->set_status (1) ; 

a_step2 ->add_predecessor  {iny_step )  ; 
a_step2->set_deadline(the_step->get_deadline( ) ) ; 
a_step2->set_priority (the_step->get_priority ( ) ) ; 

a_step2->putObject ( ) ; 
my_step->putObject ( ) ; 

} 

} 

else{ 

nTy_step->set_step_type(4)  ; 
my_step->secondary_input (the_step- 
>secondary_input { ) ) ; 

iry_step->set_status  (1); 

iny_step->set_deadline(the_step->get_deadline{ ) )  ; 
iny_step->set_priority  (the_step->get_priority ( ) ) ; 
iny_step->puCObjecc  ( ) ; 
the_£tep->set_status (1) ; 
the_step->putObject ( ) ; 

) 

) 

OC_transactionCoinmit  ( )  ; 

OC_close( )  ; 


void  commit_substep (char*  dbname.int  step_id) 

{ 

OC^open ( dbname ) ; 

OC_transactionStart ( ) ; 

STEP*  the_step=f ind_step (step_id) ; 
if  (the_step  ==  NULL) 

cout  «*there  is  no  such  step  \n“  ; 
else{ 

int  nty_status  =  the_step->get_status  ()  ; 
if(  iry_status  !=3) 

cout  «  “cannot  commit  an  un-assigned  step  \n"; 
else{ 

if {the_step->get_step_type ( ) ==0) 
cout  «the_step->Name( )  «  '  is  not  a  substep!!  \n“; 
else{ 

char  an_id[64]; 

sprintf {an_id, "%d" , the_step->get^step_id{ ) ) ; 

My_String 
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temp=My_String { " . ‘ ) +My_String { " step_“ ) +My_String (an_id) ; 
dirNamePtr  =(char*)  temp; 

COMP_REFERENCE*  my_ref=  the_step- 
>get_base_version ( ) ; 

char*  thename  =  my_ref->get_priv_name ( ) ; 
int  var  =  my_ref '>get_variation_no ( ) ; 
int  ver  =  rny_ref  ~>get_version_no  ( )  ; 
char  protoname  1 64 ]  ; 

sprintf  (protoname,  "%s  %d;%d'‘,  thename,  var,  ver)  ; 
//  cout  <<“pr'  toname:  “  <<protoname  <<“\n‘; 

List*  iny_list=  the_step->primary_input  { )  ; 
COMP_REFERENCE*  a_refl; 
a_refl  =  (COMP_REFEREMCE*  )iny_list- 
>getEntityElement (0) ; 

char  *iny_name=  new  char (strlen (a_ref  1- 
>get_priv_name ())+l); 

strcpy  (iny_name,  a^ref  l->get_priv_name  ( )  )  ; 
if (the_step->get_step_type ( ) ==1) { 

My^String  ten^4=  My_String  (iriy_name) -10  ; 
char  *compName  =  (char*)  temp4; 

//  cout  <<  "compName:  ‘  <<compName  <<"\n*; 

COMPONENT*  new_comp; 

new_comp  =  Add^new_version (protoname, compName) ; 
if {new_comp==  NULL) 

cout  <<  “the  dam  error  again  \n“; 
else{ 

the_step->add_output (new_comp) ; 
the_step->set_status (4) ; 
the_step->putObject ( ) ; 

} 

} 

else( 

if (the_step->get_step^type( ) ==  4) { 

My_String  temp4=  My_String (my_name) -9 ; 
char  *compName  =  (char*)  temp4; 

COMPONENT*  new_comp ; 

new_comp  =  Add_new_version (protoname, compName) ; 
i f ( new_comp = =  NULL ) 

cout  «  “the  dam  error  again  \n“; 
else{ 

the_step->add_output (new_comp) ; 
the_step->set_status (4) ; 
the_step->putObject ( ) ; 

) 
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} 

else 

{ 

My^String  temp4=  My_String  (iny_name) -9; 
char  *compName  =  (char*)  temp4; 

List*  a_list=  the_step->preceded_by(); 
STEfty_step={STEP*)a_list->getEntityElement (0) ; 
List*  the_listainy_step->output  ( )  ; 

COMPONENT*  aComp= ( COMPONENT* ) 

the_list->getEntityElement (0 ) ; 
if (the_step->get_step_type ( ) ==2) { 

My^String  tempi (My_String (dirNamePtr ) 
+My_String{  */* )  •*•  My^String  (a_ref  1- 
>get_priv_name ( ) ) ) ; 

char  *temp2=  (char*)  tempi; 
ifstream  myFile (temp2) ;  //=(char*)0; 
if (myFile) { 

TEXT_OBJECT  *a_text_obj ; 
cout  «*Creating  text  object:  “ 

«a_refl->get_priv_name  ( )  <<•.,.  \n" ; 
a_text_obj*  new  TEXT_OBJECT ( ) ; 
a_text_obj->append(a_refl“>get_priv_name( ) , 

myFile) ; 

aComp->replaceTextObject (a_text_obj) ; 
aComp->putObject ( ) ; 
the^step->add_output (aComp) ; 
the_step->set_status (4) ; 
the_step->putObject ( ) ; 

) 

else  cout  <<"there  is  no  such  file:  ■  <<a_refl- 
>get_priv_name ( )  <<  * \n“ ; 

} 

else{ 

i f ( the_step->get_step_type ( ) ==3 ) { 
char*  badr»  new  char[strlen(aComp- 
>CompnentName ())+!]; 

strcpy  (badr,  aCoinp->CompnentName  ( )  )  ; 
char*  salah=get_last_toIcen  (badr )  ; 
COMPONENT*  new_comp; 
new_comp  = 

Add_new_version (protoname, compName) ; 

if(new_comp  '.a  NULL)  { 

new_comp->replace_subconponent (aComp, salah) ; 
new_comp->putObject { ) ; 
the_step->add_output (new_comp) ; 
the_step->set_status (4) ; 
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the_step-->putObject  ( )  ; 
} 

} 

} 

} 

) 

} 

} 

) 

OC_transactionCoiranit  (OC_doNothing)  ; 
OC_close ( ) ; 


void  coinmit_step  (char*  dbname.int  step_id) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( ) ; 

char  temp(641; 

char*  iny_step_naine=“step_“; 

sprint f  (temp,  “%s%d“,  nTy_step_name,  step_id)  ; 

STEP*  the_step=(STEP*)OC_lookup  (temp) ; 
if  (the^step  =*  NULL) 

coot  <<" there  is  no  such  step  \n"; 
else{ 

int  my_status  =  the_step->get_status ( ) ; 
if(  my_status  !=3) 

cout  <<  “cannot  commit  un-assigned  step  \n" ; 
else{ 

COMP_REFERENCE*  my_ref=  the_step- 
>get_base^version ( ) ; 

char*  thename  =  my_ref ->get_priv_name ( ) ; 
int  var  =  my_ref->get_variation_no ( ) ; 
int  ver  =  my_ref->get_version_no ( ) ; 
char  protoname[64); 

sprint f (protoname,  "%s  %d;%d",  thename, var , ver) 

if (the_step->get_step_type( )  ==0) 

{ 

List*  my_list  =  the_step->substep(); 
if (my_list->Cardinality ( ) ==  1) 

{ 

STEP*  iny_step=(STEP*)my_list- 
>getEntityElement (0) ; 

List*  a_list  =  niy_step->output  ( )  ; 

COMPONENT*  my_comp; 

itty_comp  =  (COMPONENT* )  a_l  ist  - 
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>getEntityElement (0) ; 

char* 

teinpl=generate_new_conf iguration(protoname,  niy_comp)  ; 

upciate_base_versions  (step_id,  tempi)  ; 
the_step->set_status(4)  ; 
the_step->putObject ( ) ; 

} 

else 


{ 

List*  niy_list  =  the_step->substep  ( )  ; 
Listiterator  nTy_iterator  (my_list )  ; 
while  (iny_iterator  .moreData  ( )  ) 

{ 


STEP* 

iny_step=  (STEP* )  (Entity*  )iny_iterator  ( )  ; 

if  (niy_step->get_step_type  ( )  =  =  3 ) 

{ 

List*  a_list  =  iny_step->output  ( )  ; 
COMPONENT*  my_comp; 
iny_comp  =  ( COMPONENT* )  a_l  i  s  t  - 

>getEntityElement (0) ; 

char* 

teinpl=generate_new_conf iguration (protoname,  my_comp)  ; 

the_step->set_status (4 ) ; 
update_base_versions (step^id, tempi) ; 
the_step->putObject ( ) ; 

} 

> 

} 

} 

else 

cout  «•  Sorry  this  is  not  a  top  level  step  \n" 
) 

} 

OC_transactionCoinmit  (OC_doNothing)  ; 

OC^close ( ) ; 

) 


void  update_base_versions { int  step_id, char*  tempi) 

{ 

char  propto_name [64 ] ; 
int  var,  ver; 

sscanf  (tempi, '%s  %d:%d’',  propto_name,  &var,  &ver)  ; 
STEP*  the_step  =  find_step(step_id) ; 
if(the_step  !=  NULL) { 
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COMP_REFERENCE*  a_ref=:  the. ''tep- >get_base_vers ion  (  )  ; 

Set  'aSet  =  (Set  • ) OC_lookup ( * step_set " ) ; 

//  Ask  the  set  object  for  an  iterator 
Iterator*  aniterator  =  aSet ->getIterator { ) ; 

STEP*  iny_step; 

//  For  each  item  in  the  iterator 
while (anIterator->moreData () )  { 

//  Get  the  item 

my_step= ( STEP* ) ( Entity  * ) (anIterator->operator ()()); 
if (my_step->get_status ( )  <=  3){ 

COMP_REFERENCE*  my_ref=  my_step->get_base_version { ) ; 
if (strcmp (a_ref ->get_priv_name ( ) , 

my_ref->get_priv_name{ ) ) ==0  && 
a_ref->get_version_no ( ) ==  my_ref ->get_version_no ( ) 

&& 

a..ref->get_variation_no  ( )  ==  iny_ref  - 
>get_variation_no ( ) ) { 

my_ref->set_version_no(  ver); 
iny_ref->set_variation_no  (var )  ; 
nty_ref->putObject  ( )  ; 
iny_step->putObject  ( )  ; 

} 

} 

} 

) 

} 

mainstep.cxx 

#include  <Database.h> 

#include  <Directory .h> 

#include  <string.h> 

#include  <Set.h> 

#include  "step_Operations .h* 

extern  "C* 

{ 

char  *getenv (const  char  *); 

) 

//Globals 

char*  dirNamePtr= “ . ^ ; 
int  warning_time=l ; 
char  *dbName=  "supportDB"; 

char*  DESlGN_DATABASE_DIRECTORy="DesignDB" ; 
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char*  thepath  =(char*)0; 
char*  v_path  a(chdr*)0; 
COMPONENT*  compPtr=NULL; 


int  maindnt  argc.char  *argv()) 

{ 

char  *opcion= (char*) 0; 
char  •aName=  (char*)  es¬ 
char  "aNamels (char* ) 0 ; 
char  *dbName= (char* ) 0 ; 
char  theochername (641; 
char  tmpl(64]; 
char  tinp2  [  64  ]  ; 
char  “tmpSs (char*) 0; 
char  tinp4(64]; 
char  *tmp5= (char* ) 0 ; 
char  tinp6(64]; 
char  *tnip7=  (char*)  0; 
int  nTy_step_id; 

int  a_step_id,  a_value,a_valuel,a_value2; 

char  *user_naine  =  getenv(  “USER* )  ; 

if  (argvClJ) 

{ 

dbName  *  new  char(strlen(argv[l])+l); 
strepy (dbName, argv (11); 

} 

if  (argv (2 ] ) 

{ 

option  s  new  char [strlen(argv[2] ) +1] ; 
strepy (option,  argv [21 ) ; 

} 

//  Create  step 

if (option (0)  =='1')( 

//  get  proto  name 

aNamel  =  new  char  [strlen  (argv  [3  1 ) -t-1  ] 
strepy (aNamel, argv [3] ) ; 
aName  =  new  char [strlen(argv[41 ) +11 ; 
strcpy(aName,argv[4l ) ; 
sprint f (tmpl, "%s  %s“ , aNamel, aName) ; 
aNamel  =  new  char[strlen{argv[5l)+l]; 
strepy (aNamel, argv [51 ) ; 
aName  =  new  char [strlen (argv [61 ) +11; 
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strcpy{aName,argv[6] ) ; 

sprint  f  ( tinp2 ,  *  %s  %s  * ,  aNamel ,  aName )  ; 

create^step (dbName, tmpl, tmp2) ; 


} 

else  if(option[0]  ==  ‘2'){ 

//Show  Step 

aName  =  new  char (strlen (argv [ 3 ] ) +1 ) ; 
strcpy ( aName , argv [ 3 ] ) ; 
sscanf  (aName,  '‘%d'' ,  &my_step_id)  ; 
s  how_s  t  ep ( dbName , my_s  t  ep_i d ) ; 

} 

else  if(option[0J  ==  ‘3'){ 

//  show  steps  of  certain  status 

aName  =  new  char[strlen{argv[3))+l]; 
strcpy (aName, argv [3] ) ; 
show_steps (dbName, aName) ; 

} 

else  if(option[0]  ==  '4’){ 

//  update  step 

aName  =  new  char [strlen (argv ( 3 ] ) +1 ] ; 
strcpy ( aName , argv (31); 
sscanf (aName, *%d* , &my^step_id) ; 

//  update  deadline 

aNamel  =  new  charlstrlen(argv(4] ) +1] ; 
strcpy  (aNamel,  argv [4] )  ,- 
aName  =  new  char [strlen(argv[5] ) +1] ; 
strcpy ( aName , argv [5]); 
sprint f (tmpl, “%s  %s" , aNamel, aName) ; 

//  add  primary  input 

aNamel  =  new  char[strlen(argv(6] ) +1] ; 
strcpy ( aNamel , argv ( 6 ] ) ; 
aName  a  new  char[strlen(argv[71)+l]; 
strcpy (aName, argv [7] ) ; 
sprint f (tmp2, •%s  %s* , aNamel, aName) ; 

//delete  primary  input 

tmp3  =  new  char[strlen(argvt8])+l]; 
strcpy (tmp3, argv (8) ) ; 

//  add  secondary  input 

aNamel  =  new  char[strlen(argv[9])+l]; 
strcpy (aNamel. argv [9] ) ; 
aName  =  new  char(strlen(argv[10] ) +1] ; 
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strcpy (aName, argv( 10 ] ) ; 

sprint f (tmp4, ■%s  , aNamel , aName) ; 

II  delete  secondary  input 

tmp5  =  new  char(strlen(argv(ll] ) +1] 
strcpy  (tinp5,argv[  11]  )  ; 

//  add  affected_modules 
aNamel  =  new 

char[strlen(argv[12] ) +1] ; 

strcpy (aNamel, argv[ 12] ) ; 

aName  =  new  charlstrlen(argv[13] ) +1] ; 

strcpy (aName, argv [ 13 ] ) ; 

sprintf (tmp6, •%s  %s" .aNamel, aName) ; 

II  delete  af fected^modules 

tmp7  =  new  char (strlen( argv [ 14 ]) +1] 
strcpy ( tmp7 , argv [14] ) ; 

//  Update_priority 
aNamel  s  new 

char [strlen( argv [15] ) +1] ; 

strcpy (aNamel, argv[15] ) ; 
sscanf (aNamel, "%d“ , &a_value) ; 

//  Update_precedence 
aNamel  s  new 

char  [strlen  (argv [16]  )•*>!]; 

strcpy ( aNamel , argv [16] ) ; 
sscanf  (aNamel,  ■%d'' ,  &a_step_id)  ; 

/ /Upda t e_es  t ima  t  ed_du ration 
aNamel  s  new 

char [strlen (argv [17] )+lJ; 

strcpy (aNamel, argv [17] ) ; 
sscanf (aNamel, •%d* , &a_valuel) ; 

II  Update_expertise_level 
aNamel  =  new 

char[strlen (argv[18] ) +1] ; 

strcpy (aNamel, argv[18] ) ; 
sscanf (aNamel, •%d‘ ,ia_value2) ; 
Update_Step(dbName,rny_step_id,  tmpl , 

tmp2 , tmp3 , tmp4 , tmp5 , tmp6 , tmp7 , 

a_value, a_step_id, a_valuel, a_value2) ; 
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} 

else  if(option{0]  ==  '5‘){ 

//  Update_start_time 

aName  =  new  char(strlen(argv(3])-t-l]; 
strcpy  (aNaine,argv[3] )  ; 
sscanf  (aName,  “%d* ,  &ny_step_id)  ; 
aNamel  =  new  char[strlen(argv(4])+l]; 
strcpy  (aNcunel, argv[4]  )  ; 
aName  =  new  char(strlen(argv[5] ) +11 ; 
strcpy ( aName , argv [5]); 
sprint f (theothername,  •%s 

%s  * , aNamel , aName ) ; 

Upda  t  e_s  t  ar  t _t ime ( dbName , my_s  t  ep_ i d , 

theothername) ; 

} 

else  if{option[01  ==  ‘6'){ 

//  Update_f inish_time 

aName  *  new  char [strlen (argv(3 1  ) +1 ] ; 
strcpy (aName, argv [3 ] ) ; 
sscanf  (aN2une,  ’•%d* ,  &ny_step_id)  ; 
aNamel  s  new  char(strlen(argv[4))+l]; 
strcpy (aNamel, argv [41 ) ; 
aName  =  new  char [strlen (argv[51 ) +1) ; 
s  t  r cpy ( aName , argv [ 5 ) ) ; 
sprint f (theothername, •%s 

%s “ , aNamel , aName ) ; 

Updat  e_f ini sh_t ime ( dbName , my_s  t  ep_i d , 

theothername)  ; 

} 

else  if(option[0]  ==  '7'){ 

//  Update  Status 

aNcune  =  new  char(strlen(argv[3])+l]; 
strcpy (aName, argv [3] ) ; 
sscanf  (aName,  '•%d" ,  &iny_step_id)  ; 
aNcimel  =  new  char[strlen(argvt41)+l]; 
strcpy (aNamel, argv [4] ) ; 
sscanf  (aNamel,  ''%d* ,  &a_value)  ; 

Updat e_status ( dbName, my_step_id, a_ value) ; 

} 

else  if(option(0J  ==  '8’){ 

//  Update  designer 

aName  «  new  char[strlen(argv(3] ) +1] ; 
strcpy ( aName , argv [ 3 ] ) ; 
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sscanf  {aName,  *%d* ,  SLiny_step_id)  ; 
aNeunel  =  new  char  (strlen(argv(4]  ) +1]  ; 
strcpy  {aNainel,argv[4]  )  ; 


Update^designer  ( dbName ,  itiy_step_id.  aName  1 )  ; 

} 

else  if(option[OJ  ==  '9’){ 

/ /  print  commit  data 

aN^une  =  new  char tstrlen(argv(3]  ) +1]  ; 
strcpy (aName, argv [3] ) ; 
sscanf  (aName,  “%d'‘ ,  &my_step_id)  ; 
get_commit_data (dbName, my_step_id) ; 

} 

else  if(optiontO)  ==  ‘a‘){ 

//  get  scheduling  data 

aName  =  new  char[strlen(argv[3])-*-l]; 
strcpy (aName, argv [3] ) ; 
sscanf  (aName,  •%d* ,  fitnty_step_id)  ; 
aNamel  =  new  char(strlen(argv{4] ) +1] ; 
strcpy (aNamel , argv [4 ] ) ; 
aName  »  new  char (strlen(argv[51 ) +1] ; 
strcpy (aName, argv(5] ) ; 
sprint f (theothername, “%s 

%s " , aNamel , aName ) ; 

get_scheduling_data  ( dbName ,  iny_st  ep_id , 


theothername)  ; 

} 


a_value) ; 


else  if(option[01  *=  'b'){ 

//  create  substep 

aName  =  new  charlstrlen(argv[3))+lj; 

strcpy (aName, argv [3] ) ; 

sscanf (aName, ’%d* , &my_step_id) ; 

aNamel  =  new  char(strlen(argv[4) ) +1] ; 

strcpy (aNamel , argv [ 4 ) ) ; 

tmp3  a  new  char[strlen(argv[5])-t-ll; 

strcpy (tmp3, argv [5] ) ; 

tmp5  =  new  char[strlen(argv(6])+l]; 

strcpy (tmp5, argv [6] ) ; 

sprint f (theothername, “%s  %s" , tmp3, tmp5) ; 
aName  =  new  char Istrlen (argv[7] ) +1] ; 
strcpy (aName, argv [7] ) ; 
sscanf (aName, "%d* , &a_value) ; 
create_substep (dbName, my _step_id, aNamel , 
user_name,  theothername. 
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) 

else  if(option[0]  ==  *c‘){ 

//  approve  step 

aName  =  new  char [strlen(argv[3] ) +1] 
strcpy (aName, argv (3]); 
s s can f  (aName,  •%d'‘ ,  &ny_step_id)  ; 
auto_create_substeps  (dbName,rry_step_id) 

} 

else  if(option(0)  ==  ‘d*){ 

//  commit  substep 

aName  =  new  char  [strlen  (argv [3  ]  )  ■*•1  ] 
strcpy (aName, argv [3]); 
sscanf (aName, *%d“ , &my_step_id) ; 
commit_substep (dbName,my_step_id) ; 

) 

else  if(option(0]  *=  ‘e*){ 

//  commit  step 

aName  =  new  char [strlen(argv[3) ) +1] 
strcpy (aName, argv [ 3 ] ) ; 
sscanf  (aName,  "%d" ,  &rry_step_id)  ; 
commit_step(dbName,my_step_id) ; 

} 

else  if(option(0J  *=  •f'){ 

/ /  r emove_  s  t  ep_f  r om^s chedu 1 e 

aName  =  new  char [strlen (argv (3) ) +1] 
strcpy (aName, argv [3] ) ; 
aNamel  =  new  char[strlen(argv(4))+l]; 
strcpy (aNaroel, argv [4] ) ; 
tmp3  =  new  char [strlen(argv[5] ) +1J ; 
strcpy ( tmp3 , argv [ 5 ] ) ; 
sprint  f  (theothername,  '■%s 

%s " , aNamel , tmp3 ) ; 

remove_step_f rom_schedule ( dbName, aName, 

theothername) ; 

) 

else  if(option[0)  ==  •g’){ 

//  Dump  step  components 

aName  *  new  char [strlen(argv[3] ) +1] 
strcpy (aName, argv[3] ) ; 
sscanf  (aName,  ■%d* ,  Scmy_step_id)  ; 
dump_step_components  (dbName,  iny_step_id) 

} 

else  if(option(01  ==  'h') 

//  find  assigned  step 

find_assigned_step (dbName, 
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user_naine)  ; 

else  if|option[01  ==  ‘i‘)[ 

//  Suspend/ Abandon  Step 

aName  =  new  char [strlen(argv[3] ) +1] 
strcpy (aName, argv ( 3 ] ) ; 
sscanf (aName, *%d* , &my^step_id) ; 
aNamel  =  new  charlstrlen(argv[4])+l]; 
strcpy (aNamel, argv (41 ) ; 
sscanf (aNamel, *%d" , &a_value) ; 
suspend_abandon_step ;dbName, my_step_id, 

a_value) ; 


) 

else  if(option(0]  ==  'j‘){ 

//  Suspend/ Abandon  Step 

aName  =  new  char(strleniargv[3] ) +1] 
strcpy (aName, argv (3] ) ; 
sscanf (aName, •%d* , &my_step_id) ; 
Update_deadline (dbName, rry_step_id)  ; 

} 

else  if(option(01  ==  •k*){ 

//  Suspend/ Abandon  Step 

aName  =  new  char[strlen(argv(3] ) +1] 
strcpy (aName, argv [3] ) ; 
aNamel  *  new  char(strlen(argv[41 ) -t-l] ; 
strcpy (aNamel, argv (4] ) ; 
sprint f ( theothername , ■%s  %s" , aName, 


aNamel ) ; 


Early_warning(dbName, theothername) ; 


} 

else  ii(optionl01  *»  •!'){ 

//  get  scheduling  data 

aName  »  new  char(strlen{argv(3] )+l] 
strcpy (aName, argv [3] ) ; 
aNamel  »  new  chartstrlen(argv[41)+l]; 
strcpy (aNamel, argv[4) ) ; 
sprintf (theothername, "%s 

%s • , aName , aNamel ) ; 

aName  =  new  char [strlen{argv[5] ) +1] ; 
s  t  rcpy ( aName , argv (51); 


get_scheduling_data_2 (dbName, theothername. 


aName)  ; 

} 

else  if(option(01  =»  'm’){ 

aName  =  new  char (strlen (argv(3 1 ) +1 1 ; 
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strcpy {aName, argv [ 3 ) ) ; 

aNamel=  new  char[strlen(argv[4])+l]; 

strcpy (aNamel, argv [4] ) ; 

sprint f (theothername, *%s 

%s  ,  aName .  aName  1 )  ; 

aName  =  new  char(strlen(argv[5])-*-ll; 
strcpy (aName, argv [5] ) ; 
get_Sched_data^l (dbName, ‘MySchedule*  , 

theothername, aName) 

} 

else 

cout  « "Wrong  Option;  *  «  option  <<  " 

Try  again  \n" ; 

} 


2.  Class  Component 
componenLli 

#ifndef  _ ^COMPONENT_H 

#define  _ COMPONENT_H 

#include  <Object.h> 
iinclude  <Dictionary .h> 
#include  <Type,h> 
iinclude  <List.h> 

#include  <Reference.h> 
//#include  "ReferenceMacros .h" 
#include  <stream.h> 

#ifndef  _ TEXT_OBJECT_H 

#include  ■text_object .h" 

#endi£ 


extern  *C" 

{ 

# include  <sys/time.h> 

#include  <sys/types .h> 

#include  <string.h> 

} 

//  Class  // 

//  Defines  a  COMPONENT  class.  The  class  COMPONENT  is  a 
derived 
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//  class  of  Object, 
class  COMPONENT  : 
public  Object 
{ 

private  : 

int 

int 

char* 

char* 

time_t 

char* 

char* 

Reference 

//  parent  relationship 
Reference 

//  child  relationship 

Reference 

Reference 


version_id; 
variation_id; 
theName ; 
priv^author ; 
DateCreated; 
previous_ver s ion ; 
next_version; 
part_of_list ; 

sub_coinponent_list  ; 

used_by_list ; 
text_object_list ; 


public: 

//  COMPONENT  — APL  ONTOS  required  constructor 
COMPONENT (APL  *theAPL) ; 


//  Constructs  a  COMPONENT  object 

COMPONENT (char*  name, int  ver,  int  var) ; 


//  ONTOS  method  for  savig  Object  as  pesistent 

Object . 


virtual  void  putObject (OC^Boolean 
deallocatesFALSE) ; 


//  ONTOS  method  for  deleting  an  Object 
virtual  void  deleteObject {OC_Boolean 

deallocate=FALSE) ; 

//  ONTOS  heap  mangagement  method. 

virtual  void  Destroy (Boolean  abort  =  FALSE); 

//  Return  the  ONTOS  Type  of  class  COMPONENT, 
virtual  Type  *getDirectType ( ) ; 

//  Set  the  version  mumber 

void  versionNumber (int  ver) { 
version_id  =  ver; 

} 
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//  get  the  version  mumber 
int  versionNumber ( ) { 

return  version_id; 

} 

//  Set  the  variation  mumber 

void  variationNumber{int  vat) { 
variation^id  =  var; 

} 

//  get  the  variation  mumber 
int  variationNumber ( ) { 

return  variation_id; 

} 

//  Set  the  author  name 

void  AuthorName(char*  auth) { 
priv_author  =  auth; 

} 

//  get  the  author  name 
char*  AuthorName ( ) { 

return  priv_author; 

} 

//  Set  the  component  name 

void  CompnentName {char*  a^name) { 
theName  =  a_name; 

) 

//  get  the  component  name 
char*  CompnentName ( ) { 
return  theName; 

) 

//  set  creation  time 

time_t  setCreationDate( ) ; 

//  get  creation  time 

time_t  getCreationDate( ) { 
return  DateCreated; 

) 

//  set  previous_version 

void  set Previous_vers ion (char*  comppath) 


{ 


previous^version  =  comppath; 


//  get  previous_version 

char*  getPrevious^version ( ) { 

return  previous_version; 

} 

//  set  next_version 

void  setNext_version (char*  comppath) 

{ 

next_version  =  comppath; 

) 

char*  getNext_version ( ) { 

return  next _vers ion; 

} 

//  add  a  subcomponent 

void  addSubcomponent (COMPONENT*  otherComponent) ; 

//  add  a  parent  to  the  parent  list 
void  addParentComponent (COMPONENT* 
otherComponent) ; 

void  replace_subconponent (COMPONENT*  my^comp,  char 

*comp_neime)  ; 

//  find  component 

void  f ind^component (char  *thename) ; 

//  search  the  tree  for  a  component 

void  f ind_a_component (char  *thename) ; 

//search  the  tree  for  a  parent  of  a  component 
void  find_parenc  (char  *thenaune)  ; 

//  get  a  list  of  subcomponents 
List*  subcomponents  0 { 
return  (List*) 

sub_component_list .Binding (this) ; 


//  reset  a  list  of  subcomponents 

void  subcomponents (  List*  parts)  { 

sub_component_list . Reset (parts ,  this) ; 
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} 

//  get  a  list  of  text  objects 
List*  TextObjectList ( ) { 
return  (List*) 

text_object_list . Binding ( this) ; 

} 

//  reset  a  list  of  taxt  objects 

void  TextObjectList (  List*  parts)  { 

text_object_list . Reset (parts ,  this) ; 

} 

//  delete  the  text  objects  of  a  COMPONENT  object, 
void  deleteComponentText ( ) ; 

//  Display  the  file  names  of  the  files  contained  in 
//  the  COMPONENT  node 

void  getComponentNames ( ) ; 

//  Display  the  file  names  of  the  file  contained  in 
//  each  COMPONENT  of  the  subtree 

void  getComponentSubtreeNames ( ) ; 

//Output  the  contents  of  an  COMPONENT  node  to  files. 
Boolean  getComponent Source (char* ) ; 
void  getComponentSubtreeSource(char*) ; 

//  Inserts  a  text^object  into  the  COMPONENT  node, 
void  addTextObject (TEXT_OBJECT  *) ; 

void  replaceTextObject (TEXT_OBJECT 
_text_object) ; 

//  Output  the  .ps,  .spec,  .  .and  .a  f^es  contained  i 
//  in  the  COMPONENT  node. 

Boolean  getPSfile(char*) ; 

Boolean  getGRAPHfile(char* )  ; 

Boolean  getSPECf ile (char* ) ; 

Boolean  getIMPfile(char*)  ; 

Boolean  getSOURCEfile(char*) ; 

char  *getTEXTPtr(char*) ; 
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//  Destructor  for  the  COMPONENT  class. 
-COMPONENT { )  { 

Destroy (FALSE) ; 

)  ; 


class  Sequencer  :  public  Object 
{ 

private  : 

int  theValue; 

public : 

Sequencer (APL  *theAPL) ; 
Sequencer (char*  a^name) ; 
Type  •getDirectType( ) ; 


}; 


//increment  the  sequencer  and  return  the  new  value, 
int  getValue ( ) ; 

//  read  the  value  of  the  sequencer  (how  many 
//  variation  a  component  has) 
int  readValue(){ 

return  theValue; 

} 


#endif  //  _ COMPONENT_H 

componentcxx  *••••••••••••••••••> 

#ifndef  _ DDBDEFINES.H 

#include  "ddbdef ines .h" 
#endif 

#include  <Type.h> 

#include  <Object.h> 

#include  <GlobalEntities .h> 
#include  <Database.h> 
#include  <Directory  .h> 


extern  "C" 

{ 

char  *getenv (const  char  *); 
#include  <strings.h> 

} 


#ifndef  _ ^COMPONENT_H 

#include  'component .h* 
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#endif 


//extern  userPtr; 
extern  char  *thepath; 
extern  char  *dirNamePtr ; 
extern  COMPONENT*  compPtr; 

//  ONTOS  required  constructor  // 

Sequencer: ; Sequencer (APL  ’theAPL) rObject (theAPL) 

{ 

} 

//  Creates  a  Sequencer 

Sequencer; : Sequencer (char*  name) ; Object (name) 

{ 

initDirectType  (  (Type* ) OC_loo)cup  ( "Sequencer" )  ) 
//directType (getDirectType ( ) ) ; 
theValue=l ; 

) 

Type*  Sequencer : ; getDirectType ( ) 

{ 

return  ( Type* )OC_lookup{ "Sequencer" ) ; 

} 

int  Sequencer : '.getValue  ( ) 

{ 

r.heValue  *  theValue  +1; 
return  theValue; 

) 

COMPONENT: : COMPONENT (APL  *theAPL) : 

Ou,  'theAPD 
{ 

} 

//  Creates  a  list  to  hold  text  objects,  then  reset  a 
reference 

//  to  point  to  the  list. 

COMPONENT:  .‘COMPONENT (char*  name,  int  var,  int  ver)  : 
Object (name) 

{ 

initDirectType  (  (Type*  )OC_loo)cup  ( "COMPONENT" )  ) 
version_id  =  ver; 
variation_id  =  var; 
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theNdine  =  Name  ( )  ; 
priv_author  =  0; 
char  *userPtr  =  getenv ( "USER" ) ; 
if  (userPtr)  { 

priv_author  =  new  char 

(strlen{userPcr) +1] ; 

if  (priv_author) 

strcpy (priv_author. 


} 


userPtr ) 


DateCreated  =  setCreationDate { ) ; 
previous_version=0 ; 
next_version=0 ; 
part_of_list . Init (new 

List( (Type* )OC_lookup( “COMPONENT") ) .this) ; 
sub_component_list . Init (new 

List ( (Type*)  (X:_lookup( “COMPONENT" ) ) .this) ; 
used_by_list .Init (new 

List ( (Type* ) OC_lookup ( “COMPONENT" ) ) , this ) ; 
text_object_list . Init (new 

List ( (Type*)OC_lookup( “TEXT_OBJECT“ ) ) . this) ; 

) 


//  Member  Functions  // 

//  returns  the  ONTOS  Type  for  the  COMPONENT  class. 

Type  *COMPONENT: :getDirectType( ) 

{ 

return  (Type* ) OC_lookup ( “COMPONENT" ) ; 

} 

void  COMPONENT: :putObject ((X_Boolean  deallocate) 

{ 

//saves  structure  of  the  component  lists 
( (List* ) part_of_lisc . Binding ( this) ) 

->putObject (FALSE) 

( (List*) sub_component_list .Binding(this) ) 

->putObject (FALSE) 

( (List* ) used_by_list . Binding ( this) ) - 
>putObject (FALSE) ; 

( ( List *)text_object_list. Binding (this) ) 
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>putObject (FALSE)  ; 

//  saves  the  component  itself 
Object : :putObject (deallocate) ; 

) 


void  COMPONENT: rdeleteObject (OC_Boolean  deallocate) 

{ 

//deletes  structure  of  the  component  lists 
( (List* ) part_of_list .Binding (this) ) 
->deleteObject (deallocate) ; 

( (List* ) sub_component_list . Binding ( this ) ) 
->deleteObject (deallocate) ; 

( ( List *)used_by_list. Binding (this) ) 

->deleteObject (deallocate) ; 

( (List*) text_object_list. Binding (this) ) 
->deleteObject (deallocate) ; 

//  deletes  the  component  itself 
Object: :deleteObject (deallocate) ; 


} 


void  COMPONENT:  .-Destroy  (OC_Boolean  aborted) 

{ 

Entity*  ent; 

ent  =  part_of_list. Binding ( this ) ; 
delete  ent; 

ent  =  sub_component_list .Binding (this) ; 
delete  ent; 

ent  =  used_by„l ist. Binding ( this ) ; 
delete  ent; 

ent  =  text_object_list.Binding(this) ; 
delete  ent; 
if  (aborted)  Object: 

Destroy (aborted) ; 

} 

//  set  creation  time 

time_t  COMPONENT: : setCreationDate ( ) 

{ 

time_t  *irytloc  =0; 
time_t  theTime; 

return  theTime  =  time (micloc) ; 


//  delete  the  text  objects  of  a  COMPONENT  object. 
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void  COMPONENT: : deleteComponentText ( ) 

{ 

List  *ny_list  =  TextObjectList ( )  ; 
Listiterator  my_iterator  (riiy_list)  ; 
TEXT_OBv7ECT  *  the_text_ob j  ect  ; 


while (iny_iterator  .moreData  ( ) ) 

{ 

the_text_object  = 

(TEXT_OBJECT*) (Entity* ) my.iterator ( ) ; 
the_text^object  ->  deleteObject ( ) ; 


> 

//  check  if  the  conponent  name  matches  certain  string 
void  COMPONENT; : find_conponent (char  *thename) 

{ 

char*  nameptr=0; 

nameptr  =  CompnentName I ) ♦strlen (CompnentName ())- 
strlen (thename) ; 

if  (strcmp(  nameptr, thename) ==0) 
thepath=CompnentName ( ) ; 


} 


void  COMPONENT: : find_a_component (char  * thename) 

{ 

f ind_component (thename) ; 
if(thepath=s  0) 

{ 

List  *my_list  = 

(List*) sub_component_list .Binding (this) 
Listiterator  iny_iterator  (ny_list)  ; 
COMPONENT  *theComponent; 
while (my_iterator.moreData ( ) ) 

{ 


theComponent  = 

(COMPONENT*)  { Entity* ) rny_iterator  ( )  ; 
theComponent - 

>find_a_component (thename) ; 

} 


} 


} 


void  COMPONENT: : find^parent (char  *thename) 
{ 

List  *my_list  = 

(List* ) sub_component_list .Binding (this) ; 
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Listiterator  niy_iterator  (niy_list )  ; 
COMPONENT  *theCoinponent  ; 
while  (iry_iterator  .moreData  ( ) ) 

{ 


theComponent  = 

(COMPONENT*)  (Entity*  )iny_iterator  ( )  ; 
if (strcmp (theComponent 
->CompnentName { ) , thename ) ==0 ) 

{ 

compPtr=  this; 
return; 

} 

else 


>find_parent (thename) ; 
} 


} 


theComponent - 


//Displays  the  name  of  each  text  object  in  a  COMPONENT  object, 
void  COMPONENT :: getComponentNames ( ) 

{ 

cout  <<  NameO  «*\n*; 

List  *my_list  = 

(List*) text_object^list .Binding{this) ; 

Listiterator  my_iterator (my_list ) ; 

TEXT_OBJECT  *  the_text_ob j  ect ; 


while  (iny_it  era  tor  .moreData  ( ) ) 
{ 


(TEXT_OBJECT*) 

} 


the_text_object  = 
(Entity*)iny_iterator  ( )  ; 
the_text_object  -> 


} 


displayFileName ( )  ; 


void  COMPONENT: :getComponentSubtreeNames ( ) 

{ 

getComponentNames ( ) ; 

List  *iny_list  = 

(List* ) sub_component_l is t .Binding (this) ; 

Listiterator  my_iterator(iny^list)  ; 

COMPONENT  * theComponent; 
while (my^iterator .moreData ( ) ) 

{ 

theComponent  = 

(COMPONENT*) (Entity*)my_iterator ( ) ; 
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theComponent- 

>getComponentSubtreeNames ( ) ; 

) 


} 


Boolean  COMPONENT:  :getCojnponentSource( char  *fileMode) 

{ 

List  *n!y_list  = 

(List*) text _object_list .Binding (this) ; 

Listiterator  nTy_iterator  (nTy_list)  ; 

TEXT.OBJECT  *  the_text_ob j  ect ; 

Boolean  write_failed  =  FALSE; 
while (iny_iterator.moreData() ) 

{ 

the_text_object  = 

( TEXT_OBJECT* ) (Entity* )  nv^iterator ( ) ; 
if  ( !the_text_object  -> 

rebuildTextFile(fileMode) ) 
write_f ailed  »  TRUE; 

} 

if  (write^failed) 

return  FAILED; 

else 


return  SUCCESS; 


} 


void  rnMPONENT: :getComponentSubtreeSource(char  *fileMode) 

{ 

getCoinponentSource(fileMode) ; 

List  *nny_list  * 

(List*)  sub_coniponent_list  .Binding (this)  ; 

Listiterator  iny_iterator  (nty_list)  ; 

COMPONENT  *theCoinponent; 
while (ny_iterator.inoreData ( ) ) 

{ 

theComponent  = 

(COMPONENT*)  (Entity* ) iry_iterator  ( )  ; 
theComponent 

->getComponentSubtreeSource ( f ileMode) ; 

} 

} 


void  COMPONENT: :addText Object (TEXT^OBJECT  *my_text_object ) 
{ 
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List  *iny^list  =  TextObjectList  ( )  ; 
my^list  '>  Insert (my _text_object )  ; 
my^list  '■>  putObjectO; 


void  COMPONENT: : replaceTextObject (TEXT_OBJECT 
*my_text_ob j  ect ) 

{ 


OC_Boolean  FOUND=FALSE; 

char  •a_name=new  char [strlen (my_text_object 

->getFileNaine  ( )  )  t-l  ] 

strcpy (a^name,  my_text_object->getFileName ( ) ) ; 

//  cout  «"new:  ‘  «  a_name  «“\n"; 

List  "my^list  =  TextObjectList () ; 

Listiterator  ny_iterator (my_list ) ; 

TEXT_OBJECT*  a_text_ob j  ect ; 

while (my^iterator .moreData ( ) &&  ! FOUND) 

{ 

a_text_object  = 

(TEXT_OBJECT*) (Entity*)my_iterator ( ) ; 
char  *a_namel=new 
char (strlen (a^text^object 


->getFileNai7ie  ())+!] 
strcpy (a_namel,  a_text_object 

->getFileName { ) ) ; 

//  cout  «*old:  "  <<  a^namel  <<"\n" 

i € { strcmp ( a_name ,  a_namel ) ==0 ) { 

ny_l i s  t - >Remove { my^l i s  t 


>Index(a_text_object) ) ; 
>Insert  (niy_text_object )  ; 

} 

) 


nty_list- 
FOUND  =  TRUE; 


ny^list  ->  putObjectO; 
putObject ( )  ; 


Boolean  COMPONENT: ; get PSfile (char  *fileMode) 
{ 

List  *my_list  = 

(List* ) text_object_list .Binding (this) ; 

Listiterator  iry_iterator  (iry_list )  ; 

while (my_iterator.moreData ( ) ) 
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{ 

TEXT_OBJECT  *Lhe_text_object  a 
(TEXT_OBJECT*)  (Entity*  )iny_it  era  tor  ( )  ; 
char  *the_f ile_naine  =  the_text_object 

->getFileName ( ) ; 
the_f  ile_naines  (the_f  ile_name  + 

( strlen ( the_text_ob j  ect - 

>getFileName ( ) ) 

-3) )  ; 

if  (strcinp(the_file_naine,  "  .ps- )  ==0) 

{ 

if  {the_text_object 
->rebuildTextFile ( f ileMode) ) ; 
return  SUCCESS; 


Boolean  COMPONENT: :getSPECfile{char  *fileMode) 

( 


List  *iny_list  * 

(List*) text^object_list .Binding (this) ; 

Listiterator  my^iterator  (iny_list)  ; 
while (ny_iterator .moreData ( ) ) 

{ 

TEXT_OBJECT  *the_text_ob3ect  = 
(TEXT_OBJECT*) (Entity *)  iny_iterator ( ) ; 
char  *the_file_naine  =  the_text_object 

->getFileName ( ) ; 
the_f  ile^names  ( the_f  i le_naine  + 
(strlen(the_text_object->getFileName 0 ) - 

10) )  ; 


if (strcrop (the_f ile_name. 

{ 


} 


} 


} 


.  spec . psdl " ) =*0) 


if  {the_text_object 
->rebuildTextFile ( f ileMode) ) 
return  SUCCESS; 

else 


return  FAILED; 


239 


Boolean  COMPONENT: :getGRAPHfile (char  *fileMode) 

{ 

List  *iny_list  = 

(List*) text_object_list .Binding (this) ; 

Listiterator  iiiy_iterator  (my_list )  ; 
while  (iny_iterator. moreData  ( )  ) 

{ 

TEXT_OBJECT  *the_text_obj ect  = 

( TEXT_OBJECT* ) (Entity *) my_iterator ( ) ; 
char  *the_f ile_name  =  the_text_object 

->getFileNaine  ( )  ; 
the_f  ile_name=  (the_file_naine  + 

(strlen (the_text_object->getFileName ( ) ) 

6) )  ; 

if (strcmp (the_f ile_name, " .graph" ) ==0) 


if  {the_text_object 


>rebuildTextFile ( fileMode) ) 


else 


return  SUCCESS; 


return  FAILED; 


Boolean  COMPONENT; :getIMPfile (char  *fileMode) 

{ 

List  *my_list  = 

(List*) text_object_list .Binding (this) ; 

Listiterator  ny_iterator (ny_list) ; 
while (iny_iterator. moreData  ( ) ) 

{ 

TEXT_OBJECT  *the_text_object  = 
(TEXT_OBJECT*)  (Entity*  )iny_iterator  ( )  ; 
char  *the_Eile_name  =  the_text_object 

->getFileName ( ) ; 
the_f ile_name= (the_f ile_name  + 

(strlen (the_text_object->getFileName ( 1 


if (strcmp (the_f ile_name, " . imp .psdl " ) ==0 
{ 
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} 


if  (the_text_object 
->rebuildTextFile ( f ileMode) ) 
return  SUCCESS; 

else 


return  FAILED; 


Boolean  COMPONENT: : get SOURCEfile( char  *fileMode) 

{ 

List  *my_list  * 

(List*) text_object_list .Binding (this) ; 

Listiterator  my_iterator (ny_list ) ; 
while  (iny_iterator. moreData  ( ) ) 

{ 

TEXT_OBJECT  *the_text_object  » 
(TEXT_OBJECT*) (Entity*)ny_iterator ( ) ; 
char  *the_f ile^name  =  the_text_object 

->getFileNaine  ( ) ; 
the_file_naine»(the_file^naune 
(strlen(the_text_object->getFileName ( ) ) - 


2) )  ; 


if  (strcit«p(the_file_naine,  •  .a" )  *=0) 

{ 

if  (the_text_object 
->rebuildTextFile ( f ileMode) ) 
return  SUCCESS; 

else 


return  FAILED; 


} 


} 


} 


char  ‘COMPONENT: :getTEXTPtr (char  *TextType) 
{ 


List  *my_list  = 

(List*) text_object_list .Binding (this) ; 

Listiterator  ny_iterator(iry_list); 
while (my^iterator.moreData ( ) ) 

{ 

TEXT_OBJECT  *the_text_object  = 
(TEXT_OBJECT*)  (Entity*  )iiTy_iterator  ( )  ; 
char  *the_file_name  =  the_text_object 
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>getFileName ( ) ) 


->getFileName ( ) ; 
char  *the_f ile=  ( the_f ile..naine  + 

( strlen ( the_t ext_ob j  ect - 


(strlen (Text Type) ) ) ) ; 

if  (strcinp(the_file,  TextType)  ==0) 

{ 

return  the_text_object- 


>text ( ) ; 


} 


} 

return  (char  *)0; 


) 


//  add  a  subcomponent 

void  COMPONENT: raddSubcomponent (COMPONENT*  otherComponent ) 
{ 

List  *child_nodes  =  (List  *) 

sub_component_list .Binding (this) ; 


if 

{ 

subcomponent 

} 

if 

( 

subcomponent 

} 


( Ithis) 


cout  «  *<ERROR: 
to  a  null  component\n‘ ; 
return; 

( !child_nodes) 

cout  «  "<ERROR: 
to  a  componentXn* ; 
return; 


cannot  add  a 


cannot  add  a  null 


child_nodes->Insert (otherComponent) ; 
child_nodes->putObject ( ) ; 
putObject () ; 


void 

{ 


COMPONENT: : replace_subconponent (COMPONENT*  iny_comp, 

char*  comp_name) 


OC.Boolean  FOUND=FALSE; 

char*  salah=new  char[strlen(comp_name) +1] ; 
strcpy (salah, comp_name) ; 

//  cout  «"comp:  "  <<  salah  <<"\n"; 
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List  *niy_list  =  (List  *) 

sub^component^list .Binding (this) ; 

Listiterator  nTy_iCerator(mv_list)  ; 
while (niy_iterator. moreData  ( )  &&  (FOUND)  { 
COMPOt>(ENT*  a_comp  = 

(COMPONENT*)  (Entity* )iny_iterator  { )  ; 
char*  test=a_comp 
->CoinpnentNaine( )  +strlen  (a_conip 
->CompnentNaine  ( )  )  -strlen  (salah)  ; 

//  cout  <<"old:  "  <<test  <<"\n“ 

if (strcmp(test,  salah)==0){ 

nTy_l  i  s  t  -  >Reino  ve  ( my_l  i  s  t 

->Index (a_comp) ) ; 
nTy_list->Insert  (iny_comp)  ; 
FOUND  =  TRUE; 


void  COMPONENT: laddParentComponent (COMPONENT* 
otherComponent ) 

{ 

List  *parent_nodes  =  (List 
*)part_of_list .Binding(this) ; 
if  ((this) 

{ 

cout  «  •<ERROR:  cannot  add  a 
subcomponent  to  a  null  component \n " ; 

return; 

) 

if  ( ! parent_nodes ) 

{ 

cout  «  •<ERROR;  cannot  add  a  null 
subcomponent  to  a  component \n * ; 

return; 

} 

parent_nodes->Insert (otherComponent) ; 
parent_nodes->putObject ( ) ; 
putObject ( ) ; 


coinp_Operations.h  ••••••••••••**•' 

# i  f ndef  ^COMP_OPERATIONS_H 

#define  _ ^COMP_OPERATICNS_H 
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# include “component . h“ 

char*  get_last_token (char*  comp_name) ; 

char*  get_red_of_extras  (char*  cotnp_name,  char*  a_name)  ; 
OC_Boolean  set_New_prototype_Di rectory  (char*  aName) ; 
OC_Boolean  set_new_component_dir (char*  aName); 

(Xr_Boolean  set_new_version_dir (char*  aName,  int  var,  int 
ver)  ; 

void  Add^SubComponent (char*  dbName.char*  namel,char* 
a_ncime2 ,  char*  a_name3 )  ; 

void  CreateComponent (char*  aName, int  var,  int  ver) ; 
void  ShowComponent_subtree (char*  dbName,char*  namel,  char* 
aName)  ; 

void  ShowComponent_subtree(char*  namel,  char*  aName); 
void  ShowComponent (char*  dbName.char*  namel,  char*  aName); 
void  DeleteComponent (char*  dbName.char*  namel, char*  aName); 
void  DumpComponent (char*  namel. char*  aName); 
void  CreatePrototype(char*  dbName.char*  aName); 
void  find_component_path(char*  comp_name,  char*  a_name) ; 
void  Find_Parent (char*  protoname. char *comp_naune) ; 

COMPONENT*  Add_new_version  (char*  protoname. char* comp_name) ; 
void  DumpComponent_subtree (char*  dbname.char* 
protoname. char*  comp_name) ; 
void  Show_prototypes (char*  dbName) ; 

void  find_version  path (char*  protoname, ch?r*comp_name) ; 
v’oid  Dump_version (char*  dbname,  char*  pror.oname, char* 
comp_name) ; 

char*  generate_new_configurat ion (char*  prctoname,  COMPONENT* 
iny_comp)  ; 

void  Dvunp_Imp_File(char*  dbname,  char*  protoname, char* 
comp_name)  ; 

void  Dump_Spec_File (char*  dbname,  char*  protoname, char* 
comp_name) ; 

void  Dump_Imp_Filel (char*  protoname, char*  comp_name) ; 
void  Duinp_Spec_Filel  (char*  protoname,  char*  comp_neune)  ; 
void  Show_component_vers ions (char*  dbname, char* 
protoname, char* comp_name) ; 

#endif  / /COMP_OPERATIONS_H 

comp_^Op€rations.cxx***************************************************** 

#include  <Database.h> 

#include  <Directory .h> 

#include  <string.h> 

#include  <stream.h> 


244 


•include  "text^object .h“ 

•include  "component .h“ 

•include  "My^String.h" 

•include  "comp_Operations .h" 

•  include  ■•step_Operations  .h* 

//  Globals 

extern  char  *dirNamePtr; 

extern  char*  DESIGN_DATABASE_DIRECTORY; 

extern  char*  thepath  ; 

extern  char*  v^path  ; 

extern  COMPONENT*  compPtr; 

static  char  *my_ext 151 ={“. spec .psdl “ ,  ".imp.psdl",  “.ps“, 
* .graph* , " .a* } ; 

char*  get_last_token(char*  comp_name) 

{ 

char  *separator=*>“ ; 
char*  wordl; 
char*  word2; 

wordl=strtok (conp^neune,  separator)  ; 
while  (wordl  isNULDC 
word2=wordl; 

wordl=strtok(NULL,  separator) ; 

} 

return  word2; 

} 

char*  get_red_of_extras (char*  comp^neune,  char*  a_name) 

{ 

char  *salah=new  chartstrlen(comp_name) +1) ; 
strcpy  (salah,coinp_name) ; 
char  *badra  new  char(strlen(a_name) +1) ; 
s  t  r cpy ( badr , a_name ) ; 

int  n  =strlen(salah)-2*strlen(badr) -4; 
char*  word2anew  char(n+l); 
strncpy (word2 , salah, n) ; 
word2 (n+1]  =  ' \0  '  ; 
return  word2; 


) 

void  CreatePrototype(char*  dbncune,  char*  aName) 
{ 

OC_open (dbname) ; 

OC_transactionStart ( ) ; 
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if  (set_New_prototype_Directory (aName) ) 
CreateComponent (  aName« 1,1); 
OC_transactionCoinmit  (CX:_doNc thing)  ; 

OC_close ( ) ; 

) 

void  CreateComponent (char*  aName, int  var.int  ver) 

{ 

cout  <<  “Creating  a  COMPONENT:  *  <<  aName  <<  “ 

. . . \n“ ; 

COMPONENT  *my_component  =  new 
COMPONENT ( aName , var . ver ) ; 

int  i  ; 

for(i=0;  i<=4;++i){ 

My_String  tempi (My_String (dirNamePtr) + 
My_String ( * / * ) +My_String (aName) + 
My_String(my_ext (i) ) ) ; 

char  •temp2=  (char*)  tempi; 

My_String  temp3 (My_String (aName) + 

My_String (my_ext [ i ] ) ) ; 

char  *temp4=  (char*)  temp3 ; 
ifstream  iryFile (temp2)  ;  //=(char*)0; 
if (myFile) { 

TEXT_OBJECT  *a_text_obj ; 

a_text_obj=  new  TEXT_OBJECT(); 
a_text_obj->append(temp4,  myFile) 
my_component - 

>addTextObject (a_text_obj ) ; 

} 

} 

iny_component->putOb>ect  ( )  ; 

} 


void  Add_SubComponent (char*  dbname,  char* 

protonaune,  char*comp_name,  char*  parent ) 


OC_open ( dbname ) ; 

OC_transactionStart ( )  ; 
char  temp [64]; 
int  ver,  var; 

f ind_component_path (protoname , parent ) ; 
if(thepath  !=0){ 

sscanf (comp_name, *%s  %d; %d* , temp, &var ,  &ver) ; 
My_String  ptrl=  My_String( "''")  + (My„String(thepath)  - 


My_String (parent )  )  ; 


\ 


char  *ptrs  (char*)  ptrl; 

Directory*  a_directory=  (Directory* ) OC_loo)cup (ptr)  ; 
if (a_directory ) ( 

OC_set Wor)c ingDi rectory (a_di rectory)  ;  // 

(char* ) the_dir) ; 

if (set_new_component_dir (comp_name) ) { 

//  cout  «  "these  are  the  values  ‘  <<  ver  «  var 

«"\n"  ; 

CreateComponent (temp, var, ver) ; 

COMPONENT  *my_componentl  =  (COMPONENT*) 

OC_loo)<up (temp)  ; 

char*  my_comp 

strcat (my_comp, thepath) ; 

COMPONENT  *my_component2  =  (COMPONENT*) 

OC_loolcup ( thepath)  ; 

if (my_componentl==NULL) 

cout  «*  There  is  no  such  a  component  \n“; 
else{ 

if (my_component2==NULL) 

cout  <<“  There  is  no  such  parent  component  \n“; 
else{ 

my_component2->addSubcomponent (my_componentl ) ; 
my_component 1 - 

>add Pa rent Component (my_component2 ) ; 

} 

} 

} 

} 

else 

cout  <<  "there  is  no  such  parent  directory  \n“ ; 

) 

else 

cout  <<  “there  is  no  such  parent  component  \n"; 
OC_transactionCommit (OC^doNo thing) ; 

OC_close ( ) ; 

} 

COMPONENT*  Add_new_version (  char*  protoname, char*  p_name) 

( 

char*  comp_name=  new  char(strlen(p_name)+l); 
strcpy (comp_name,p_name) ; 

My_String  temp3 (My_String (comp_name) + 

My_String ( *_seq“ ) ) ; 

char  *temp2=  (char*)  temp3; 
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int  ver.var; 

f  ind_coinponent_path(protoname,  comp_name)  ; 
if (thepath  ! =0) { 

My_String  ptrl=  My_String('‘''*)  +  (My_String(thepath)- 

My_String  (coinp_name)  )  ; 

char  *ptr=  (char*)  ptrl; 

COMPONENT  *iny_coinponentl  =  (COMPONENT*) 

OC_loo)cup  { thepath)  ; 

if  (nty_componentl  !=  NULL)  { 
ver  =  iny_componentl->versionNuniber()+l; 
OC_setVtfor)<ingDirectory  (ptr)  ; 
if  (iny_componentl->getNext_version ( )  ==  0) 
var  =  nv_componentl->v^riationNuinber  ( )  ; 
else{ 

Sequencer*  my _sequencer={  Sequencer *)OC_loo)cup(temp2)  ; 
if  (iny_sequencer!  =  NULL)  { 

var  =  niy_sequencer->getValue  ( )  ; 
ny_sequencer->putObject ( ) ; 

} 

} 

//  OC_setWor)cingDirectory  (ptr)  ; 

if (  set_new_version_dir (comp_name, var, ver) ) { 
CreateComponent  (comp_nanie,  var,  ver)  ; 

COMPONENT  *iny_component2  =  (COMPONENT*) 

OC_loo)cup  ( comp_name )  ; 
if (my_componentl->getNext_version ( ) ==  0) 

iny_coinponentl->setNext_version  (iny_component2 

->CompnentName ( ) ) ; 

my_componentl->putObject ( ) ; 

iny_coinponent  2  ->set  Previous_ver  s  ion  ( itTy_component  1 

->CompnentName ( ) ) ; 
List*  my_list  *  iny_componentl->subComponents ( ) ; 
Iterator*  iny_iterator  =  iny_list->getIterator  ( )  ; 
//  For  each  item  in  the  iterator 
while (my_iterator->moreData ( ) )  { 

COMPONENT*  a_comp=( COMPONENT*) (Entity*) 

( ( *my_iterator) ()); 

my_component2->addSubcomponent  (a_comp)  ,- 

} 

my_component2->putObject ( )  ; 
return  my_component2 ; 

} 

) 

else  return  NULL; 
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else  return  NULL; 


) 

char*  generate_new^conf iguration(char*  protoname, COMPONENT* 
my^comp ) 

{ 

int  var,  ver, varl, verl; 
char  temp [64]; 
char  temp2[64]; 
char  tempi [64] ; 
compPtr  =NULL; 

char*  badr=  new  char(strlen(iTv_comp- 
>CompnentName ( ) ) +1 ] ; 

strcpy  (badr ,  iry_comp->CompnentName  ( ) )  ; 

char*  salahl=get_iast_token (badr) ; 

char*  comp^namel =new  char[strlen (salahl) +1] ; 

strcpy ( comp_namel , salahl ) ; 

sscanf (protoname, “%s* ,temp) ; 

if  (strcmp(comp_namel,temp)=sO) { 

varl  s  iny_comp->variationNumber  { )  ; 
verl  a  my_comp->versionNumber ( ) ; 
sprint  f  (tempi , '•%s  %d:%d*,temp,  varl,  verl); 
return  tempi; 

} 

else{ 

char*  a_name=  my_comp->getPrevious_version () ; 
Find_Parent (protoname, a_name) ; 
if(compPtr  !=NULL){ 

ver  =  compPtr->versionNumber  0  +1 ; 
char*  ptrlanew  char [strlen (compPtr- 
>CompnentName ())+!]; 

strcpy (ptrl , compPtr->CompnentName ( ) ) ; 
char*  salah=get_last_token (ptrl) ; 
char*  comp_name=new  char[strlen(salah)+l]; 
strcpy  (con?)_name,  sal  ah) ; 

My_String  temp=  My_String  (“''")  + (My _String  (compPtr 
->CompnentName ( ) ) -My_String (comp_name) ) ; 
char*  ptr=(char*)  temp; 

Directory*  my _dir= (Directory *) OC_lookup (ptr) ; 
if (my_dir) { 

OC_setWorkingDirectory  (rny_dir)  ; 
if (compPtr->getNext_version ( ) ==  0 ) 
var  =  compPtr->variationNumber ( ) ; 
else{ 

sprintf  (tempi,  ••%s%s* ,  comp_name,  "_seq" )  ; 
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Sequencer* 

my^sequencers  ( Sequencer* )  OC_lookup  ( teinp2 )  ; 

if  (iny_sequencer !  =  NULL)  { 

var  =  rny_sequencer->getValue  ( )  ; 
niy_sequencer->putObject  { )  ; 

) 

) 

if  {set_new_version_dir  (comp_naine,  var,  ver)  ) 

{ 

COMPONENT  *iny_component  =  new 

COMPONENT  ( con>p_name .  va  r ,  ver )  ; 
iny_coinponent->TextObjectList  (compPtr 

->TextObjectList ( ) ) 
if (compPtr->geCNext_version ( ) ==  0) 

{ 

coinpPtr->seCNext_version  (iry_component 

->CompnentName ( ) ) ; 

con\pPtr->putObject  ( )  ; 

} 

nv_coinponent  -  >set  Previous_vers  ion  ( compPt  r 

->CompnentName ( ) ) ; 

List*  iny_list  =  compPtr->subCoinponents  ( )  ; 
Iterator*  iny_iterator  =  niy_list->getIterator  0  ; 
//  For  each  item  in  the  iterator 
while  (iny_iterator->moreData  ( )  )  { 

COMPONENT*  a_comp= (COMPONENT*) (Entity*) 

( ( *niy_iterator)  ( )  )  ; 

ir(y_component->addSubcomponent  (a_comp)  ; 

} 

iny_component  - 

>replace_subconponent  (niy_comp,  comp_ncunel )  ; 

iny_component->putObject  ( )  ; 
generate_new_conf  iguration  (protoname,  iny_component ) 
} 

} 

else  cout  <<“  no  such  dir:*  <<  ptr  <<  * \n* ; 

) 

else  cout  «  "no  such  comp:  "  <<  a_name  <<*\n*; 

} 

} 


void  ShowComponent (char*  dbname,  char* 

protoname, char* comp_name) 


{ 


OC_open (dbname) ; 


250 


OC^transactionStart ( ) ; 

find_component_path (protoname, comp_name) ; 
if{thepath  !=0){ 

COMPONENT  •iny_component=  (COMPONENT*) 
CX:_lookup(thepath)  ; 

if (my_component==  NULL) { 

cout  <<  "Object:  •  <<  comp_name  <<"  is  not  in 

DDB. . .\n" ; 

} 

else{ 

iny_component->getComponentNames  ( )  ; 

) 

} 

OC^transactionCommit (OC_doNothing) ; 

OC_close( ) ; 

} 

void  ShowComponent_subtree (char*  dbname,  char* 
protoname,  char  *comp_naine) 

{ 

OC^open ( dbname ) ; 

OC_transactionStart ( ) ; 

find_component_path (protoname, comp_name) ; 
if(thepath  !a0){ 

COMPONENT  *iny_component=  (COMPONENT*) 

OC_loo)cup  (thepath)  ; 

if  {iny_component==  NULL)  { 

cout  «  "Object;  "  «  comp_naune  <<*  is  not  in 
DDB. . .\n"; 

} 

else{ 

my_component->getComponentSubtreeNames ( ) ; 

} 

} 

/ /ShowComponent.subtree (protoname, comp_name) ; 
OC^transactionCommit (OC^doNothing) ; 

OC_close( ) ; 

} 


void  DeleteComponent (char*  dbname,  char*  protoname, 

char*  comp_name) 


OC_open { dbname ) ; 

OC_transactionStart ( ) ; 

find_component_path (protoname, comp_name) ; 


251 


if(thepath  !=0){ 

COMPONENT  •my_component=  (COMPONENT*) 

OC_lookup ( thepath) ; 

if  (njy_conponent==  NULL) 

cout  <<  “Object:  “  «  comp_name  <<"  is  not  in 
DDB. . . \n“ ; 

else{ 

rny_component->deleteComponentText  ( )  ; 
iry_component->deleteObject  (FALSE)  ; 

) 

) 

else 

cout  «  “there  is  no  such  component  \n“; 
OC_transactionCommit (OC_doNo thing) ; 

OC_close( ) ; 

} 

void  DumpComponent (char*  protoname, char*  comp_name) 

( 

find_component_path (protoname, comp_name) ; 
if (thepath  5=0) { 

COMPONENT  *tny_component=  (COMPONENT*) 

OC^lookup (thepath) ; 

if  (iTy_component==  NULL) 

cout  <<  “Object:  "  «  comp_name  <<*  is  not  in 
DDB. . . \n“ ; 

else{ 

iny'^component->getComponentSource  ( “w* )  ; 

} 

) 

else 

cout  <<  “there  is  no  such  component  \n"; 

} 

void  Dump_Imp^Fi lei (char*  protoname, char*  comp_name) 

{ 

find_component_path (protoname, comp_name) ; 
if (thepath  ! =0) { 

COMPONENT  *my_component=  (COMPONENT*) 

OC_lookup ( thepath) ; 

i  f  ( iny_componen  t = =  NULL ) 

cout  <<  “Object:  “  «  comp_name  «“  is  not  in 
DDB. . .\n“ ; 

else{ 

my —Component ->getIMPfile ( “w" ) ; 

) 
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} 

else 

cout  <<  “there  is  no  such  component  \n"; 


void  Duinp_Spec_Filel (char*  protoname, char*  comp_name) 

{ 

find_component_path (protoname, comp_name) ; 
if(thepath  1=0) ( 

COMPONENT  *my_component=  (COMPONENT*) 

OC_loolcup  (thepath)  ; 

if (my_componenta=  NULL) 

cout  <<  "Object:  *  «  comp_name  <<“  is  not  in 
DDE.  .  An"  ; 

else{ 

iny_component->getSPECf  ile  ( "w" )  ; 

} 

} 

else 

cout  <<  "there  is  no  such  component  \n“ ; 


void 

{ 


DumpComponent_subtree (char*  dbname,  char* 

protoname, char*  comp_name) 


OC^open ( dbname ) ; 

OC_transactionStart ( ) ; 

find_component_path (protoname, comp_name) ; 
if(thepath  !=0){ 

COMPONENT  *my_con^onent=  (COMPONENT*) 

OC_lookup (thepath) ; 

if (my_component==  NULL) 

cout  «  "Object:  "  «  comp_name  «"  is  not  in 


DDE. . . \n* ; 

else 

my_component->getComponentSubtreeSource( "w" ) ; 


) 

else 

cout  <<  "there  is  no  such  component  \n"; 
OC^transactionCommit (OC_doNothing) ; 

OC_close( ) ; 


void  Dump_version (char*  dbname,  char*  protoname, char* 

comp_name ) 
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{ 

OC_open { dbname ) ; 

OC_transactionStart ( ) ; 
find_version_path (protoname, comp^name) ; 
if(v_path  !=0){ 

//  cout  <<  v_path  «  “\n*; 

COMPONENT  *my_component=  (COMPONENT*) 

OC_loo)cup  (v_path)  ; 

if  (iny_component  =  =  NULL) 

cout  <<  ‘Object:  “  <<  comp_name  <<“  is  not  in 
DDB. . . \n‘; 

else 

nTy^component->getromponentSubtreeSource  ( *w" )  ; 


} 

else 

cout  «  ‘there  is  no  such  component  \n‘; 
OC_transactionCommit (OC_doNo thing) ; 

OC_close ( ) ; 


void  Dump_Imp_File(char*  dbname,  char*  protoname, char* 

comp_name) 


{ 

OC_open ( dbname ) ; 

OC_transactionStart ( ) ; 
find_version_path (protoname, comp_name) ; 
if (v_path  ! =0) { 

//  cout  <<  v_path  «  ‘Xn"; 

COMPONENT  *my ..components  (COMPONENT*) 

OC_lookup (v_path) ; 

if  (nty_component==  NULL) 

cout  <<  ‘Object:  ‘  c<  comp_name  <<‘  is  not  in 


DDB. . . \n‘ ; 

else 

ny_component->getIMPf ile ( ‘w‘ ) ; 


} 

else 

cout  «  ‘there  is  no  such  component  \n“; 
OC_transactionCommit (OC_doNothing) ; 

OC^close ( ) ; 

} 

void  Dump_Spec..File  (char*  dbname,  char*  protoname,  char* 

comp_name ) 
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( 

OC_open (dbname) ; 

OC^transactionStart ( ) ; 
f ind^vers ion_path ( protoname , comp_name ) ; 
if(v_path  !a0){ 

//  cout  «  v_path  «  “\n*; 

COMPONENT  *iny_componenta  (COMPONENT*) 
(X_loolcup(v_path)  ; 

if (my_component=a  NULL) 

cout  <<  'Object:  •  «  comp_name  «'  is  not  in 
DDB. . .\n'; 

else 

iny_component->getSPECf  ile  ( “W  )  ; 


} 

else 

cout  «  “there  is  no  such  component  Sn“; 
OC_transactionCommit (OC_doNothing) ; 

OC_close ( )  ; 

} 

OC^Boolean  set_New_prototype^Directory (char*  aName) 

{ 

//  char  dir_nameI64] ; 

Directory  *prototype_dir  *  (Directory* ) 0 ; 

Directory  *ddbRootDir  =  (Directory* ) 0 ; 

Directory  *coinp_dir=  (Directory*)  0; 
ddbRootDir  =  (Directory  *) 

OC_lookup (DESIGN_DATABASE_DIRECTORy) ; 
if (ddbRootDir) 

OC_setWor)cingDi  rectory  (ddbRootDir)  ; 

else 

{ 

ddbRootDir  =  new  Directory (DESIGN_DATABASE_DIRECTORY) 
ddbRootDir  ->  putObjectO; 

OC_setWor)cingDi rectory  (ddbRootDir)  ; 

) 

My_String  temp (My _String (aName) +My_String ( “_dir“ ) ) ; 
char*  dir_name= (char*)  temp; 

prototype_dir=  (Directory  *)  OC_loo)cup  (dir_name)  ; 
if  (prototype_dir) 

{ 

//(X:_setWor)cingDirectory  (prototype_dir)  ; 
cout  <<  “Prototype:  “  <<  aName  «  “  already  existin'' 
return  FALSE; 

} 
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else  { 

prototype_dir  =  new  Directory(dir_name); 
prototype^dir  ->  putObject(); 
CXr.setWorkingDirectory (prototype_dir) ; 

My_String 

tempi  {My_String  (aName)  ■*-My_String(  ■'_seq" )  )  ; 

char*  seq_name  =  (char*)  tempi; 

II  cout  <<“Seq_name:  “  <<  seq_name  <<"\n*; 

Sequencer*  nty_sequencer=  new  Sequencer  (seq_name)  ; 
iny_sequencer->putObject  ( )  ; 

My_String  temp2 (My_String (aName) +My_String (“ 11 “ ) ) ; 
char  *p_dir  =  (char* ) temp2 ; 
comp_dir  =  new  Directory (p_dir) ; 
comp_dir  ->  putObjectO; 

CXr_setWor)cingDirectory  (comp^dir)  ; 
return  TRUE; 

> 


OC_Boolean  set_new_component_dir (char*  aName) 

{  ~ 

int  myversO; 
int  myvar=0; 
char  temp(64]; 
char  tempi (64]; 
char  temp2(64]; 

sscanf (aName  "%s  %d:%d*,  temp, &myvar,  &myver); 
sprint f  (tempi,  *%s%d%d*,  temp,myvar,nTyver)  ; 
sprintf (temp2  "%s%s*,  temp,  "_dir'); 

Directory  *comp_dir=  (Directory  *)  OC_loo)cup (temp2 )  ; 
if (comp_dir) 

{ 

//OC^setWorkingDirectory (comp_dir) ; 

cout  «  "component:  "  <<  temp  <<"  already  exist\n"; 
return  FALSE; 

} 

else 

{ 

comp_dir  =  new  Directory ( temp2 ) ; 
comp_dir  ->  putObjectO; 

OC_setWorkingDirectory  (comp^dir) ; 

II  create  a  sequencer  object 
char  seq_name ( 64 ] ; 

sprintf (seq_name, "%s%s" , temp, •_seq" ) ; 

Sequencer*  ny_sequencer=  new  Sequencer {seq_name) ; 
my_sequencer->putObject ( ) ; 
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//cout  «  "the  new  component_dir :  "  <<  teinp2  <<*\n“; 
Directory  *version_dir=  new  Directory (tempi ) ; 
version_dir  ->  putObjectO; 

OC_setWorkingDirectory ( version_dir) ; 
return  TRUE; 

} 


(X:_Boolean  set_new_version_dir (char*  aName,  int  var,  int  ver) 
{ 

char  tempi [64]; 

sprintf (tempi, "%s%d%d‘,  aName, var, ver) ; 

Directory  *version_dir=  (Directory  *)  OC_lookup (tempi ) ; 
if (version_dir) 

{ 

(DC_setWorkingDirectory  (version_dir )  ; 
cout  «  ‘version.dir :  ‘  «  tempi  «’  already  existVn*; 
return  FALSE; 

} 

else 

{ 

version^dir  =  new  Directory (tempi ) ; 
version_dir  ->  putObject ( ) ; 

(X:_setWorkingDirectory (version_dir) ; 

//  cout  <<  "the  new  version^dir:  "  <<  tempi  <<*\n"; 

return  TRUE; 

} 


void  f ind_component_path (char*  protoname, char *comp_name) 
{ 

char  dir_name(64] ; 
char  temp[64]; 
thepath=0 ; 
int  ver,  var; 

Directory  *prototype_dir  =  (Directory* , o ; 

Directory  *ddbRootDir  =  (Directory* ) 0 ; 

Directory  *comp_dir= (Directory* ) 0 ; 
ddbRootDir  =  (Directory  *) 

OC_lookup (DESIGN_DATABASE_DIRECTORY) ; 
if (ddbRootDir) 

{ 

OC^setWorkingDirectory (ddbRootDir) ; 

} 
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else{ 

cout  «  "there  is  no  database  as:  "« 
DESIGN_DATABASE_DIRECTORY  « * \n “ ; 
return; 

} 

s s can f (protoname,  “%s  %d:%d*,  temp,  &var,  &ver) ; 
sprint f (dir_name, “%s%s“ ,  temp, "_dir' ) ; 
prototype_dir=  (Directory  •)  OC_lookup (dir_name) ; 
if  (prototype_dir) 

{ 

OC_setWorkingDirectory (prototype_dir) ; 

) 

else{ 

cout  <<  “there  is  no  prototype  as:  “<<  dir_name  <<"\n“; 
return; 

) 

sprintf (dir_name, “%s%d%d“ ,  temp,  var,ver); 
comp_dir=  (Directory  *)  OC^lookup (di rename ) ; 
if ( lcomp_dir) 

{ 

cout  <<  “there  is  no  such  version  as:  “<<  temp  <<  var 
«ver  «"\n“; 

return; 

} 

else{ 

OC_setWorkingDirectory (comp_dir) ; 

COMPONENT*  rny_components (COMPONENT* )OC_lookup( temp) ; 
my^component->f  ind^a_coinponent  (comp_name)  ; 

} 


void  Find_ Pa rent (char*  protoname, char*comp_name) 
{ 

char  dir_name(64] ; 
char  temp(64]; 
thepathaO; 
int  ver,  var; 

Directory  *prototype_dir  a  (Directory* ) 0 ; 
Directory  *ddbRootDir  =  (Directory *) 0 ; 
Directory  *comp_dir= (Directory*) 0 ; 
ddbRootDir  =  (Directory  *) 

OC_lookup (DESIGN_DATABASE_DIRECTORY) ; 
if (ddbRootDir) 

{ 

OC_setWorkingDirectory (ddbRootDir ) ; 

) 


258 


else{ 

cout<<‘ there  is  no  database  as: 

"  «DESIGN_DATABASE_DIRECTORY  «  •  \ n ‘  ; 
return; 

} 

sscanf (protoname,  “%s  %d:%d*.  temp,  &var,  &ver) ; 
sprintf (dir_name, "%s%s“ ,  temp, *_dir* ) ; 
prototype_dira  (Directory  •)  0C_ 1 oo k up (di rename ) ; 
if  (prototype_dir ) 

{ 

OC^setWorkingDirectory (prototype_dir) ; 

} 

else{ 

cout  <<  "there  is  no  prototype  as:  "<<  dir^name  <<'’\n“ 
return; 

) 

sprintf (dir_name, “%s%d%d* ,  temp,  var,ver); 
comp^dirs  (Directory  *)  OC^lookup (dir_name) ; 
if ( Icomp.dir) 

{ 

cout  «  "there  is  no  such  version  as:  "<<  temp  <<  var 
«ver  «"\n"; 

return; 

} 

else{ 

OC_setWorkingDirectory (comp^dir) ; 

COMPONENT*  iny_component= (COMPONENT* ) OC_lookup (temp) ; 
my_component->f ind_parent (comp_name) ; 

) 


void  f ind_version_path(char*  protoname, char* comp_name) 

{ 

char  temp [64]; 
int  ver ,  var; 

sscanf (comp_name,  *%s  %d:%d",  temp,  &var,  &ver); 
find_component_path( protoname, temp) ; 
if (thepath  ! =0) { 

My_String  tempi (My _String (thepath) -My_String ( temp) ) 
char*  ptr=(char*)  tempi; 
char  the_comp(25G] ; 

sprintf  (the_comp,  “%s%s%s%s%d%d* ptr,">",  temp,  var,  ver )  ; 
My_S  t  r i ng  t  emp2 ( My_S  t  r i ng ( t  he_comp )  + 

My_String ( ">* ) +My_String (temp) ) ; 
v_path=  (char*) temp2; 
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) 

else 

cout  <<*  there  is  no  such  compon-^nt ;  *  <<  temp  <<"\n 


void  Show_prototypes (char*  dbname) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart { )  ; 

Directory  *ddbRootDir  =  (Directory *) 0 ; 
ddbRootDir  =  (Directory  *) 

OC_lookup (DESIGN_DATABASE_DIRECTORY) ; 
if (ddbRootDir==NULL) 

cout  <<  “NO  prototypes  in  DDB  yet  \n“; 
else{ 

OC_setWorkingDirectory (ddbRootDir) ; 

Directorylterator  my_iterator (ddbRootDir) ; 
while (my^iterator .moreData ( ) ) { 

Object*  iny_object  =  my_iterator  ( )  ; 
char*  temp  =0; 
temp=  iny_object->Name( )  ; 
char*  tempi =temp  +  9; 

char*  temp2  =  new  char[strlen(templ)-3); 
strncpy (eemp2, tempi, (strlen (tempi) -4) ) ; 
temp2 (strlen(templ) -4] = ’ \0 ’ ; 
cout  <<  temp2  «  “Xn"; 

) 

} 

OC_transactionCommit (OC_doNo thing) ; 

OC_close ( ) ; 

} 


void 

{ 


Show_component_versions (char*  dbname, char* 

protoname, char*comp_name) 


OC_open ( dbname ) ; 

OC_transactionStart ( ) ; 

find_component_path (protoname, comp_name) ; 
if (thepath  ! =0) { 

My_String  tempi (My_String ( “ ^* ) + (My_String ( thepath) 

My_String (comp_name) ) ) ; 
char*  ptr=(char*)  tempi; 

Directory  *comp_dir= (Directory  *)  OC_lookup (ptr ) ; 
if (comp_dir==NULL) 

cout  <<  "NO  such  component  in  DDB  yet  \n"; 
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else( 

OC_setWorkingDirectory ( comp_dir ) ; 

Directorylterator  rny_iterator  (comp_dir )  ; 
while(my_iterator.moreDaCa ( ) ) ( 

Object*  my .object  =  my_iterator ( ) ; 

char*  temp  =new  chartstrlen(iTTy_object->Name())+ll; 
strcpy ( temp,  my_object->Name ( ) ) ; 
char*  templ=get_last_token (temp) ; 

My.String  temp2=My_String (tempi ) -2 ; 
char  *temp3  =(char*)  temp2; 
if (strcmp(temp3, comp.name) ==0) 
cout  <<  tempi  <<  "Xn"; 

) 

) 

} 

OC.transactionCommit (OC.doNothing ) ; 

OC.close ( ) ; 


maincomp.cxx  •••••••*•••••* 

•‘include  <Database.h> 
•include  <Directory • h> 
••include  <stream.h> 

extern  "C* 

{ 

••include  ^stdlib.h> 
••include  <stddef.h> 
••include  <string.h> 

•* include  <ctype,h» 

) 


•include  *comp_Operat ions . h“ 

Olcbals 

chai  *di  r^JamePtr  -  *  .  *  ; 

'■/char  *dbMame=  " supportCB' ; 
char*  DESIOK.DATABASE.DIFECTCrY^-DesignDS" ; 
char*  thepath  =(char*)0; 
char*  v_path  =(char*)C; 

COMPCtlENT*  compPtr=HUL,L; 

int  nriain(ir.t  argc.char  *argvll,' 

{ 


261 


char  •option= (char* ) 0; 
char  *aNaine=  (char* )  0 ; 
char  *aNamel= (char* ) 0 ; 
char  *dbName= (char*) 0; 
char  thename ( 64 1 ; 
char  theochername { 64 ] ; 

if  (argv(ll ) 

{ 

dbName  =  new  char [strlen (argv [ 1 ] ) +1 ] ; 
strcpy (dbName, argv [11); 

} 

if  (argv (2) ) 

{ 

option  =  new  char (strlen (argv [2 ] ) +1 ] ; 
strcpy (option,  argv(21); 

) 

if  (option [0]  ==•!'){ 

//  Create  Prototype 

aName  =  new  char  [  strlen  (argv  ( 3  ]  )  «•!  ] 
strcpy (aName, argv [3] ) ; 

CreatePrototype (dbName,  aName); 

//exit ; 

) 

else  if(option[01  ==  ‘2*){ 

/ / ShowComponent 

aName  *  new  char  [strlen  (argv  ( 3  ]) -*-1 ) 
strcpy (aName, argv [ 3 )  )  ; 
aNamel  =  new  char[strlen(argv[4])+l); 
strcpy (aNamel , argv[4) )  ; 
sprint f ( thename, "Is  %s • , aName, aNamel ) ; 
aNamel  =  new  char [strlen (argv [ 5 1 ) ♦1) ; 
strcpy (aNamel , argv [5 ] ) ; 

ShowComponent (dbName, thename, aNamel ) ; 

/ /exit ; 

) 

else  1 f ' opt  ion [ 0 1  ==  ■3'){ 

•  show  subtree 

aName  =  new  char [strlen (argv ; 3 i ; -1 ; 
St  rcpy (aName, argv [31); 
aNamel  =  new  char  [  3(  r  len  :  argv  [  4  i  ♦  1 1  ; 
st  rcpy • aNamel , argv [ 4 ]  ) ; 
sprint:  (thename,  “’.s  %s"  ,  aName,  aNami*^!  i  ; 
aNamel  =  new  char  [  st  r  ler.  '  ar  gv  ;  5  ;  i  •  1  1  ; 
st  rcpy ( aNamel , argv [ 5  1  )  ; 


ShowComponent^subtree (dbName, thename, aNamel ) ; 

//exit ; 

) 

else  if(option[0]  ==  ‘4'){ 

//Add  subcomponent 

aName  =  new  char [strlen (argv [ 3 ) ) +1 ) 
s  t  rcpy ( aName , argv [3] ) ; 
aNamel  =  new  char  [strlen  (argv  (4  ]  ) +1  ]  ,- 
strcpy (aNamel , argv(4 ) ) ; 
sprint f (thename, •%s  %s aName, aNamel ) ; 
aName  =  new  char[strlen(argv[5])+l]; 
strcpy (aName,  argv(5) )  ; 
aNamel  =  new  char  [strlen  (argv[6] ) -*-1)  ; 
strcpy (aNamel, argv [6] ) ; 
sprint f (theothername, “%s 

%s“ , aName, aNamel ) ; 

aNamel  =  new  char  [strlen  (argv [7  ])*■!]  ; 
s t rcpy ( aNamel , argv [7]  ) ; 

Add_SubComponent (dbName, thename, 

theothername, aNamel ) ; 

//exit; 

) 

else  if(option(01  ==  '5'){ 

//  Add  new  Version 

aName  =  new  char  [ strlen  (argv  [  3 1 )  ■*•1  ] 
strcpy (aName, argv ( 3  J ) ; 
aNamel  =  new  charIstrlen(argv(4))+X]; 
strcpy (aNamel, argv [4] ) ; 
sprint f (thename, •%s  %s* , aName, aNamel ) ; 
aNamel  =  new  char[strlen(argv[51)-t-l); 
strcpy (aNamel,  argv [5) ) ; 

Add_new_version (thename, aNamel ) ; 

//exit (0) ; 

} 

else  i  t  •:  opt  ion  ( 0 )  ==  '6'){ 

/ ;  Dump  component 

aflame  =  new  char[strlen(argv[31i*ll; 

strcpy (aName, argv [ 3 ] ) ; 

aNamel  =  new  char(strlen(argv[4])*l!; 

strcpy (aNamel , argv [4 ] ) ; 

sprint f  (thename,  "Is  %s* ,  aflame,  aflanel ;  ; 

aNamel  =  new  char [ strlen (argv [ 5 ];» 1 ' ; 

s t  rcpy  { aflame  1 .  a rgv  [  5  ]  )  ; 

DumpComponent (thename, aNamel ) ; 
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} 

else  if(option(0]  ==  ‘7'){ 

aName  =  new  char[strlen(argv[3])+ll; 

strcpy (aName,argv[3] ) ; 

aNamel  =  new  char[strlen(argv[4))+l); 

strcpy  (aNainel,argv[4]  )  ; 

sprintf (thename, “%s  %s“ , aName, aNamel) ; 

aNamel  =  new  char[strlen(argv[51)+l]; 

strcpy (aNamel, argv( 5] ) ; 

DumpComponent_subtree (dbName, thename, aNamel ) ; 

) 

else  if(option[01  ==  'SMC 

Show_prototypes (dbName) ; 

} 

else  if(option(0}  ==  '9'){ 

aName  =  new  char[strlen(argv[3])+l]; 
strcpy  (aNaune, argv [3 ]  )  ; 

//aNamel  =  new  char[strlen(argv[4] ) +1] 
//strcpy  (aNcimel,argv [4] )  ; 
sprintf (thename, ■%s 

%s:%s“, aName, "1“, 'I") ; 

aName  =  new  char[strlen(argv[4])+l]; 

strcpy (aName, argv (4 J ) ; 

aNamel  =  new  char[strlen(argv[5])+lj; 

strcpy (aNamel, argv [5] ) ; 

sprintf (theothername, "%s 

%s " , aName , aNamel ) ; 

Dump_version (dbName, thename, theothername) ; 

} 

else  if(option{01  ==  'a'){ 

aName  =  new  char[3trlen(argv[3])-t-l]; 
strcpy (aName, argv [3] )  ; 

//aNamel  =  new  char(strlen(argv[4] ) +1] 
//strcpy (aNamel, argv [4] ) ; 
sprintf (thename, "%s 

%s :%s“ , aName, "I" , • 1 “ ) ; 

aName  =  new  char (strlen (argv(4) ) +1 ] ; 

strcpy (aName, argv (4 ] ) ; 

aNamel  =  new  char (strlen(argv(5] ) +1] ; 

strcpy (aNamel , argv [ 5] ) ; 

sprintf (theothername, ■%s 

%s • , aName, aNamel ) ; 

Dump_Spec_File (dbName, thename, theothername) ; 
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) 

else  if(option[01  ==  'b'){ 

aName  =  new  char[strlen(argv[3])+l); 
strcpy  (aNcune,  argv  [  3 )  )  ; 

//aNamel  =  new  char  [strlen  (argv  [4  ] ) -t-1]  ; 
//strcpy (aNamel,argv[4] ) ; 
sprint f (thename, ■%s 
%s:%s- , aName, “1" , ■!“ ) ; 

aName  =  new  char[strlen(argv[4])+l); 

strcpy (aName, argv [4] ) ; 

aNamel  =  new  char(strlen(argv[5])+l]; 

strcpy (aNamel, argv [5] ) ; 

sprintf (theothername, “%s 

%s  * , aName , aNamel ) ; 


Dump_Imp_File (dbName, thename, theothername) ; 

) 

else  if(option[01  ==  •c'){ 

//  show  subtree 

aName  =  new  char [strlen(argv[3] ) +1] ; 
strcpy (aName, argv[3] ) ; 
aNamel  =  new  char [strlen (argv [4] ) +1] ; 
strcpy ( aNamel , argv [ 4 ) ) ; 
sprint f ( thename , " %s  %s • , aName , aNamel ) ; 
aNamel  =  new  char[strlen(argv(5])+l]; 
strcpy (aNamel, argv [5 ) ) ; 
Show_component_versions (dbName, thename, 

aNamel) ; 


//exit  ; 


) 

else 

cout  « "Wrong  Option:  “  <<  option  <<  • 

Try  again  \n“; 

} 


3.  Class  Designer 

person.h  *••••••••*••♦•*••*< 

#include  <Reference .h> 
#include  <Object.h> 
finclude  <List.h> 


class  Person  :  public  Object 
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( 

private : 

int  priv_level; 

int  priv_status; 

public : 

//  Constructors 

Person(char*  name= (char*) 0, int  level=  0,  int  status=0) 
Person  (APL*); 

//  Get  direct  type 
Type  *getDirectType ( ) ; 

//  Accessors 

int  PersonLevel ( ) ; 

void  PersonLevel ( int  level); 

int  PersonStatus ( ) ; 

void  PersonStatus (int  status); 

void  display (); 

}; 


person.cxx  ************************************************************ 

iinclude  "person. h" 
iinclude  <Directory .h> 

#include  <Object.h> 
iinclude  <streain.h> 

// . . . . - . . 

//  constructors 

// - - - - 

Person Person (APL  *theAPL)  ; 

Object (theAPL) 

{ 

) 

Person :: Person (char*  name, int  level,  int  status): 

Object (name) 

( 

initDirectType  (  (Type  * )  OC_looltup  ( "  Person" )  )  ; 
priv_level  =  level; 
priv_s>.atus=  status; 
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} 


// . - . - . 

//  accessors 

// . . . . 

Type  ‘Person: :getDirectType( ) 

( 

return  (Type* )OC_lookup( “Person" ) ; 

} 


void  Person: : PersonLevel (int  level) 

{ 

priv_levtol  s  level; 

} 

int  Person : : PersonLevel { ) 

{ 

return  priv_level; 

) 


void  Person: : PersonStatus (int  status) 
{ 


priv_status=  status; 

} 

int  Person : : PersonStatus ( ) 

{ 


} 


return  priv_status; 


SetOperations.h 


# include 
#include 
iinclude 
iinclude 
#include 
#include 
#include 


<Database.h> 
<Directory .h> 
<Set .h> 
<stream.h> 
<string.h> 
<stdio.h> 

“ person. h" 


//  for  Object  naming 
//  for  Set  class 


void  trivial ( ) ; 

void  addDesigner (char*  dbName.char*  aName, int 

Level)  ; 
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void  showDesigners (char*  dbName) ; 

void  deleteDesigner (char*  dbName, char*  aName) ; 

void  changeExpLevel (char*  dbName, char*  aName,  int 

Level ) ; 

void  changeStatus (char*  dbName, char*  aName); 
void  showDesigner (char*  dbName, char*  aName); 


SetOperationsxxx 


iinclude 

#include 

#include 

tinclude 

#include 

iinclude 

iinclude 

iinclude 

iinclude 


<Database . h> 
<Directory .h> 

<Set .h> 

<List .h> 
<stream.h> 

<stdio .h> 
<Type.h> 

<Object .h> 
"SetOperations .h* 


//  for  Object  naming 
II  for  Set  class 
//  for  Set  class 


//static  char  *levels[3)  =  {"Low",  "Medium",  "High"}; 
//static  char  *States(2)  =  { "Free" , "Busy "} ; 

extern  char  *levelsl3]; 
extern  char  *State3(2]; 

//  Add  designer 

void  addDesigner (char*  dbName, char*  aName, int  Level) 

{ 

char  personstring [ 64 ] ; 

OC_open (dbName) ; 

OC_transactionStart ( ) ; 

//  Create  designer  objects  and  insert  into  set 
Person  *aPerson  =  ( Person*  )OC_loo)cup( aName )  ; 
if  (  aPerson  ==  NULL  )  ( 

//  cout  <<  “Creating  designer  object;  "<<  aName  <<  “ 

...\n"; 

//  Create  a  designer  object 

aPerson  =  new  Person (aName,  Level,  0) ; 

//  Put  it  in  the  database 
aPerson->putObject ( ) ; 

}  else 

cout  <<  "Designer  object:  "<<  aName  <<  “  already 
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exist . . . Xn” ; 


OC_transactionCoininit  ( )  ; 
OC_close ( )  ; 


void  showDesigners (char*  dbName) 

{ 

OC_open ( dbName ) ; 

OC_transactionStart { ) ; 

Instancelterator  it  ((Type*)  OC_lookup( "Person" )) ; 
while  (it .moreData ( ) )  { 

Person*  nextPerson  =  (Person*)  (Entity* ) it () ; 
cout .width (24) ; 

cout .setf (ios : : left, ios: tadjustf ield) ; 
cout  «  nextPerson->Name( ) ; 
cout .width (19) ; 

cout .setf (ios: :left, ios: :adjustf ield) ; 

cout  «levels  (nextPerson->PersonLevel  ( )  ]  ; 

cout  <<States (nextPerson->PersonStatus ( ) J  <<"\n"; 

} 

it .Destroy ( ) ; 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 

} 


//  Delete  desianf-T 

void  a.  .^-CLs^Dcoigner  (char*  dbName,  char*  aName) 

{ 

OC_open (dbName) ; 

OC^transactionStart ( ) ; 

//  Get  the  item 

Person  *aPerson  =  ( Person*  )OC_loolcup( aName )  ; 
if  (  aPerson  ==  NULL  ) 

cout  <<  “  Designer:  "  «  aName  <<  "  not  in  the  Database 

Xn"; 

//  Create  a  designer  object 
else  { 

//  Print  out  its  name 

//  cout  «  "Removing  *<<  a Person - >Name ( )  <<  "\n"; 

//  Remove  it 

aPerson->deleteObject ( ) ; 

} 

OC_transactionCommit ( ) ; 

OC_close( ) ; 
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) 


//  Change  the  designer's  expertise  level 

void  changeExpLevel ( char*  dbName, char*  aName,  int  Level) 

{ 

OC_open ( dbName ) ; 

OC_transactionStart ( )  ; 

Person  *aPerson  =  { Person* )OC_lookup( aName ) ; 
if  (  aPerson  ==  NULL  ) 

cout  <<  “  Designer:  '*  <<  aName  <<  “  not  in  the  Database 

\n-  ; 

//  change  his  expertise  level 
else  { 

//  cout  « "Designer 's  old  Expertise  =  "<<levels (aPerson- 
>PersonLevel  0  1; 

//  cout  <<  "Xn"; 

//  set  the  new  level 
aPerson->PersonLevel (  Level) ; 

//  Put  it  in  the  database 
aPerson->putObject ( ) ; 

} 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 


void  changeStatus (char*  dbName, char*  aName) 

{ 

OC_open ( dbName ) ; 

OC_transactionStart ( )  ; 
int  S  =  0; 

Person  *aPerson  =  ( Person* ) 0C_loo)<up (aName)  : 
if  (  aPerson  ==  NULL  ) 

cout  «  *  Designer:  "  «  aName  <<  "  .~>c  in  the  Database 

\n"  ; 

else  { 

//  change  his  status 
if  (aPerson->PersonStatus ( ) ==0) 

S  =  1; 
else  { 

if  (aPerson->PersonStatus ( ) ==  1) 

S  =  0; 

} 

//  sec  the  new  status 
aPerson->PersonStatus (S) ; 

//  Put  it  in  the  database 
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aPerson->putObject { ) ; 


) 

OC_transactionCommit ( ) ; 
OC_close ( ) ; 


inaindes.cxx  ********'*4'*«*****************************«*4'***<*****«****** 

#include  <string.h> 

#include  "SetOperations .h* 

//  Globals 

char  ‘levels [3]  =  {"Low*,  "Medium",  "High"); 
char  ‘States [2]  =  { "Free" . "Busy* } ; 

int  inain{int  argc.char  ‘argv[l) 

{ 

char  ‘option* (char‘) 0; 
char  ‘aName* ( char ‘ ) 0 ; 
char  ‘dbName=(char‘)0; 
char  ‘mylevel* (char‘) 0; 
int  Level =0; 
if  (argv(l]) 

{ 

dbName  *  new  char{strl€n<argv(l  J ) -t-l) 

St  rcpy ( dbName , argv [ 1 ] ) ; 

) 

if  (argv (2]) 

{ 

option  =  new  char [strlen (argv (2 ] ) +1 ] ; 
strcpy (option,  argv (21 ); 

} 

if (option [0]  ==  •  1 ' )  { 

//Add  designer 

aName  =  new  char(strlen(argv[3])+l); 

strcpy (aName, argv (3) ) ; 

mylevel*  new  char(strlen(argv[4!)-^l]; 

strcpy (my level, argv (4] ) ; 

Level* (int)  myleveltO]-  48; 
addDesigner (dbName,  aName,  Level); 

//exit ; 

} 

else  if(option[01  ==  •2'){ 
showDesigners (dbName) ; 

//exit  ; 
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) 

else  if(option(0]  ==  ‘S'jC 

aName  =  new  char [strlen (argv [3 ] ) +1 ] ; 
strcpy (aName, argv ( 3 1 ) ; 
deleteDesigner ( dbName,  aName); 

//exit ; 

} 

else  if(option(01  ==  *4'){ 

aName  =  new  char (strlen (argv (3 ]) +1 ) ; 
strcpy (aName, argv [3] ) ; 

nTylevel=  new  char  (strlen  (argv  ( 4  ]) +1 1  ; 
strcpy (mylevel,argv(4) ) ; 

Level=(int)  inylevel(0]-  48; 
changeExpLevel (dbName,  aName,  Level); 
//exit ; 

} 

else  if(option(0]  ==  '5‘){ 

aName  =  new  char(strlen(argv(3])+l]; 
strcpy (aName, argv(3) ) ; 

changeStatus (dbName,  aName); 

//exit (0)  ; 

} 

) 


4.  Class  Assignment 

sched.li  **** 

#include  <Reference .h> 

#include  <Object.h> 

#include  <List.h> 

#include  “support_classes .h“ 

class  Schedule  : 
public  Object 
{ 

private : 

char*  priv_designer ; 

Time  priv_finish; 

Time  priv_start; 

public : 

//  Constructors 

Schedule ( char*  aName= ( char* ) 0 , char* 

designer^ ( char* ) 0 ) 
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Schedule  (APL*); 

//  Get  direct  type 

Type  'getDirectType ( ) ; 

//  Accessors 

char*  AssignedDesigne. ( ) ; 
void  AssignedDesigner (char*  designer) ; 
Time  AssignmentStart ( ) ; 

void  AssignmentStart (Time  EstimatedStart )  ; 
Time  AssignmentFinishO  ; 

void  AssignmentFinish(Time  EstimatedFinish) ; 


schedcxx  •••***••*•••••*•••*•••*******•*••••*•**•••*•*•**•**•*••••*' 

#include  <Directory .h> 

#include  <Object.h> 

#include  <stream.h> 
iinclude  “sched.h* 

#include  ■support_classes .h* 

// . - . - . 

//  constructors  for  the  assignment  class 
// . - 

Schedule Schedule (APL  *theAPL)  : 

Object (theAPL) ,priv_start ( (APL*) 0) ,  priv_finish( (APL*) 0) 

{ 

} 

Schedule: ; Schedule (char*  aName.char*  designer): 

Object (aName) , 

priv_start  (0,0, 0,0,0  ,  priv_finish(0, 0, 0, 0, 0) 

{ 

initDirectType  (  (Type  * ) OC_lookup  ( "Schedule' )  ) 
priv_designer  =  designer; 

} 


// . - - - 

//  accessors 

// - - 

Type  ’Schedule: :getDirectType( ) 
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{ 


return  (Type* )OC_lookup ( “Schedule" ) ; 


) 


void  Schedule :: AssignedDesigner ( char *  designer) 

{ 

priv_designer  =  designer: 

} 

char*Schedule  : :  AssignedDesigner ( ) 

{ 

return  priv_designer; 

) 


Time  Schedule::  AssignmentStart ( ) 

{ 


} 


return  priv_start; 


void  Schedule::  AssignmentStart (Time  EstimatedStart ) 

{ 

priv_start=  EstimatedStart ; 


Time  Schedule::  AssignmentFinish ( ) 

{ 

return  priv_finish; 


} 


void  Schedule::  AssignmentFinish ( Time  EstimatedFinish) 

{ 

priv_finish=  EstimatedFinish; 

) 


schedOp.h  ************************************************************ 

iifndef  _ SCHEDOP_H 

#de£ine  _ SCHEDOP_H 

void  addAssignment ( char  ‘dbname, char *  listName,  char* 
step_id, 

char*  date,int  start,  int  f  ina.oh,  char*  aName) 
void  showSchedule ( char  *dbname, char*  listName); 
void  update_start_t ime < char  *dbname, char*  listName,  char* 

designer ) 

void  getSchedule (char  *dbname, char*  listName); 
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void  deleteSchedule (char  *dbname, char *  listName) ; 
void  deleteAssignment ( char  •dbname, char *  1 istName, char* 
step_id) ; 

void  deleteAssignment 1 (char*  listName, char*  step_id) ; 
void  gecSchedule_l ( char  *dbname, char*  listName, char* 
cur_time) ; 

#endif 


schedOp.cxx 


#include 
(♦include 
#include 
tinclude 
#include 
#include 
#include 
(♦include 
# include 


<Dacabase.h> 
<Directory . h> 
<Set . h> 

<List . h> 
<stream.h> 
<stdio.h> 
<'IVpe.h> 
<Object .h> 
<string .h> 


//  for  Object  naming 
II  for  Set  class 
II  for  Set  class 


ttinclude  "step.h* 

#include  "sched.h" 

#include  "support_ciasses . h“ 
# include  "schedOp.h* 


//  Add  Assignment 

void  addAssignment (char  *dbname, char*  listName, char*  Mystep, 
char*  Mydate,int  start, int  finish,  char*  MyD_name) 

{ 

OC^open (dbname) ; 

OC_transactionStart ( ) ; 

//  Create  assignment  object  and  insert  into  list 
List  *aList  =  (List  *) OC_loo)cup ( listName)  ; 

//  If  it  does  not  exist,  create  it 
if (aList  ==  NULL)  { 

cout  <<  "Creating  list  object  ...\n“; 

//  Create  a  new  list  called  MySchedule 
aList  =  new  List 
(  ( Type* )  OC_loo)tup  ( "  Schedule  “ )  , 

listName) ; 

} 

//cout  <<  aList->Name ( )  <<  “  already  exists. \n”; 
Schedule  *aSchedule  = 

( Schedule*  )  OC_loo)tup  (Mystep)  ; 

if  (  aSchedule  NULL  ) 


275 


{ 


//cout  <<  "Creating  record  object:  "<< 


Mystep  <<  “  ... \n* ; 

//  Create  a  designer  object 
aSchedule  =  new 
Schedule (Mystep, MyD_name) ; 

Time  startTime (Mydate) ; 
startTime=startTime+start ; 

Time  f inishTime (Mydate)  . • 
finisnTime=finishTime+finish; 
aSchedule-'»  AssignnentStart  (startTime)  ; 
aSchedule-> 

AssignmantFinish ( f inishTime) ; 

//  Put  it  in  the  database 
aScheduie->putObject ( ) ; 

//  Check  to  see  if  object  is  already  in 

list 

//  This  is  necessary  because  if  object 
//  is  already  in  list,  the  Insert  will 

add 

//  it  again  to  the  list 
if  (aList->isMember (aSchedul e)  == 


FALSE)  { 

aScheduie->Name ( )  <<  “ 


} 

} 

else 


cout  <<  "Inserting  "  << 
into  list . . . \n“ ; 

//  Insert  object  into  list 
aList->Insert (aSchedule) 
aList->putObject ( ) ; 


Time  startTime (Mydate) ; 
startTime=startTime+start ; 

Time  f inishTime (Mydate) ; 
finishTime=finishTime+finish; 
aSchedule->  AssignmentStart (startTime) ; 
aSchedule-> 

AssignmentFinish ( f inishTime) ; 

aSchedule- >AssignedDesigner (MyD_name) ; 
//  Put  it  in  the  database 
aSchedul e->putObject ( ) ; 


} 


OC_transactionCommit ( ) ; 
OC_close ( ) ; 


} 

void  update_start_C ime (char  *dbname, char*  listName,  char* 
designer) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( ) ; 

OC_Boolean  FOUND=FALSE; 

//  Create  assignment  object  and  insert  into  list 
List  *aList  =  (List  * ) OC_lookup ( lis  'ime); 

//  If  it  does  not  exist,  create  it 
if(aList  !=  NLTLL)  { 

Iterator*  aniterator  =  aList- 

>getIterator ( ) ; 


//  For  each  item  in  the  iterator 
while (anIterator->moreData ( ) && 

(FOUND)  { 

Schedule*  nextAssignment  = 
(Schedule* ) 

(Entity* ) ( ( *anIterator)  ( ) )  ; 

if (strcmp (nextAssignment 
>AssignedDesigner ( ) , designer) ==0) { 

FOUND  =  TRUE; 
nextAssignment -> 


Assignment Start {nextAssignment-> 
AssignmentStart ( ) +2 ) ; 


} 

} 

} 

OC_transactionCommit ( ) ; 
OC_close ( ) ; 


nextAssignment 
->putObject ( ) ; 


void  showSchedule (char  *dbname, char*  listName) 

{ 

oc_open ( dbname ) ; 

OC_transactionStart ( ) ; 

List  *aList  =  (List  *) OC_loo)tup  ( listName)  ; 
if(aList  ==  NULL)  { 
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cout  <<  "No  Available  Schedule 
OC_transactionCoinmit  ( )  ; 
OC_close { )  ; 
return; 


) 

if (aList->Cardinality ( ) ==0) 

cout  <<  "No  Available  Schedule 
Iterator*  aniterator  =  aLibt ->getIterator ( ) ; 

//  For  each  item  in  the  iterator 

while { anltcrat'"'- >increData( )  )  ( 

Schedule*  next Assignment  =  (Schedule*) 
(Entity*) ( {*anIterator) ( ) ) ; 
cout .width (10) ; 

cout . setf (ios : : lef t , ios : : ad just field) ; 
cout  «  nextAssignment->Name ( ) ; 
cout .width (20) ; 

cout . setf { ios : : lef t , ios : : adjust  field) ; 
cout  <<  nextAssignment-> 

AssignmentStart  ( )  .ma)ceString  ( )  ; 

cout .width (20) ; 

cout . setf (ios : : left , ios : : adjust  field) ; 
cout  «nextAssignment-> 
AssignmentFinish  ( )  .ma)ceString  ( )  ; 
cout  «  nextAssignment- 

>AssignedDesigner ( ) 

<<  "\n*; 

} 

delete  aniterator; 

OC_transactionCommit ( ) ; 

OC_close( ) ; 


void  getSchedule (char  *dbname, char*  listName) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( )  ; 
int  T2 , T3 ; 

List  *aList  =  (List  * )OC_loo)cup ( listName)  ; 
if(aList  ==  NULL)  { 

cout  <<  "No  Such  Schedule  ...\n"; 
OC_transactionCommit ( ) ; 

CX:_close  ( )  ; 
return; 
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) 

Schedule*  f irst_ass= (Schedule* ) aList 

->getEnt ityElement (0)  ; 

Time  Tl  =  f irst_ass->A3signmentStart ( )  ; 

Iterator*  aniterator  =  aList->getIterator ( ) ; 

//  For  each  item  in  the  iterator 

while {anIterator->moreData () )  { 

Schedule*  next Assignment  =  (Schedule*) 
(Entity* ) ( ( * aniterator) ( ) ) ; 
cout .width(lO) ; 

cout . set  f ( ios : : lef t , ios : : adjust  f ield ) ; 
cout  <<  nexcAssignment->Name ( ) ; 
cout .width(20) ; 

cout . set f ( ios : : lef t , ios ; : adjust  field)  ; 
T2=nextAssignment ->  AssignmentStart ( ) - 

Tl; 

cout  «  T2; 
cout .width (20) ; 

cout . set f ( ios : :left, ios: ladjustfield) ; 
73 =next Assignment ->  AssignmentFinish ( ) - 

Tl; 

cout  <<T3; 

cout  <<  nextAssignment - 

>AssignedDesigner ( ) 

«  “Xn*; 

) 

delete  aniterator; 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 

) 

void  getSchedule_l (char  *dbname, char*  listName, char* 
cur_time) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( )  ; 

List  *aList  =  (List  * )OC_loo)cup( listName )  ; 
if (aList  ==  NULL)  { 

//  cout  <<  "No  Such  Schedule 
OC_transactionCommit ( ) ; 

OC_close ( ) ; 
return; 

} 
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Time  T1 (cur_time) ; 


Iterator*  aniterator  =  aList->getIterator ( ) ; 


//  For  each  item  in  the  iterator 

while (anIterator->moreData () )  { 

Schedule*  nextAssignment  =  (Schedule*) 
(Entity* ) ( ( * an It era tor) ( ) ) ; 
if(Tl  >  nextAssignment - 

>AssignmentStart ( ) ) { 


cout .width ( 10 )  ; 

cout . setf (ios ; : left , ios : : adjust  field) ; 

cout  <<  nextAssignment - >Name ( ) 
«*\n"  ; 

cout . width ( 20 )  ; 

cout . setf ( ios :: left , ios : :adjust  f ield) ; 
int  T3=nextAssignment -> 

AssignmentFinish ( ) - 


Tl; 


cout  <<T3  <<“\n"; 
cout  <<  nextAssignment 
->AssignedDesigner  ( )  <<  “\n’'; 


} 

} 

delete  aniterator; 
OC_transactionCommit ( ) ; 
OC^close ( ) ; 


void  deleteSchedule (char  *dbname, char*  listName) 

{ 

OC_open ( dbname ) ; 

OC_transactionStart ( ) ; 

List  *aList  =  (List  * )OC_loo)<up( listName)  ; 
if(aList  ==  NULL)  { 

OC_transactionCommit ( ) ; 

OC_close ( ) ; 
return; 

) 

//Delete  the  Schedule  List 
aList->deleteCluster ( ) ; 
OC_transactionCommit ( ) ; 

OC_close ( ) ; 


void  deleteAssignment (char  *dbname. char*  listName,  char* 


step_id) 

{ 


OC_open ( dbname ) ; 

OC_transactionStart ( !  ; 

OC_Boolean  FOUND=FALSE; 

List  'aList  =  (List  • ) OC_lookup ( listName ) ; 
if(aList  ==  NULL)  { 

cout  <<  “Nothing  to  delete 
return; 


Iterator*  aniterator  =  aList - >get Iterator () ; 

//  For  each  item  in  the  iterator 

while (anIterator->moreData () &&  ! FOUND)  { 

Schedule*  nextAssignment  =  (Schedule*) 
(Entity* ) ( ( *anIterator ) ( ) ) ; 
if  (scrcmp(nextAssignir.ent->Name  ( )  , 

step_id) ==0 ) { 
aList->Remove (aList 


>Index(nextAssignment)  )  ; 
>deleteObject ( )  ; 


next Assignment  - 
FOUND  =  TRUE; 


} 


} 

) 

if  (aList->Cardinality ( )  ==  0) 

aList->deieteObject ( ) ; 

else 


aList->putObject ( ) ; 
OC_transactionCommit ( ) ; 
OC_close ( ) ; 


void  deleteAssignmentl (char*  listName,  char*  step_id) 

{ 

OC_Boolean  FOUND=FALSE; 

List  *aList  =  (List  *) OC_loo)tup ( listName)  ; 
if (aList  ==  NULL)  { 

//  cout  <<  "Nothing  to  delete  ...\n” 

return ; 

} 


Iterator*  aniterator  =  aList->getIterator ( ) ; 
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//  For  each  item  in  the  iterator 

while (anIterator->moreData  ()  &&  ’.FOUND)  { 

Schedule*  next Assignment  =  (Schedule*) 
(Entity*)  ( ( *anIterator )  ( )  )  ; 
if  (strcmp(nextAssignment->Name( )  , 

step_id) ==0 ) { 
aList ->Remove (aList 


>Index (nextAssignment ) ) ; 
>deleteObject ( ) ; 


} 

} 

aList ->putObject ( )  ; 


nextAssignment - 
FOUND  =  TRUE; 


mainsched.cxx 


#include 

#include 

#include 

#include 

#include 

^include 


<Database .h> 
<Directory . h> 
<Set .  h> 
<stream.h> 
<stdio .h> 
<string.h> 


//  for  Object  naming 
//  for  Set  class 


#include  "sched.h“ 

#include  '•support_classes .h" 

# include  “schedOp.h" 

int  maindnt  argc,char  *argv[]) 

{ 

char  ‘options (char* ) 0 ; 
char  *aName= (char* ) 0 ; 
char  *aNamel= (char*) 0; 
char  *aName2= (char* ) 0 ; 
char  *Dname= (char* ) 0 ; 
char  *dbName= (char* ) 0 ; 
char  datel ( 64 ] ; 
char  *listName=*MySchedule" ; 
int  vl,v2; 


if  (argv[l] ) 

{ 

dbName  =  new  char[strlen(argv[l])+l]; 
strcpy(dbName,argv[l] ) ; 
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} 


if  (argv(21  ) 

{ 

option  =  new  char  (strlen  (arg'/(2  ]  ) +1  ]  ; 
strcpy (option,  argv[21); 


datel , 
Dname)  ; 


if (option(0]  ==  ■  I  ■  )  ( 

//Add  designer 

aName  =  new  char  1 st r len ( argv ( 3 ] ) + 1 1 
strcpy (aName, argv [ 3 ] ) ; 

Dname=  new  char [ st r len ( argv [ 4 ] ) + 1 ] ; 

strcpy (Dname, argv [ 4 ] ) ; 

aNamel=  new  char  [strlen  (argv[5)  ) -<•1  ]  ; 

strcpy (aNamel , argv [ 5 ]  )  ; 

aName2=  new  char[strlen(argv[61)+l]; 

strcpy (aName2 , argv [ 6 ] )  ; 

sprint f (datel , " %s  %s " , aNamel , aName2 ) ; 

aNainel=  new  char[strlen(argv(7))+l]; 

strcpy (aNamel , argv [7 ] )  ; 

sscanf (aNamel , * %d" , &vl )  ; 

aName2=  new  char [ strlen (argv [8 ])» 1 ] ; 

s  t  rcpy ( aName2 , c  rgv [ 8 ] ) ; 

sscanf (aName2, *  %d“ , &v2 ) ; 

addAssigmnent (dbName,  listName, aName, 

vl , v2 , 

} 

else  if(option{0]  ==  ■2’){ 

showSchedule (dbName,  listName); 

) 

else  if(option(0]  ==  'BMC 

deleteSchedule (dbName,  listName) ; 


} 

else  if(option(0)  ==  ■4'){ 

aName  =  new  char[strlen(argv[3I)+ll; 
strcpy (aName, argv [ 3 ) ) ; 
deleteAssignment (dbName, 

listName, aName) ; 

} 

else  if(option(01  ==  '5’){ 

getSchedule (dbName,  listName) ; 

) 

else  if(option(0]  ==  '6'){ 
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aName  =  new  char [ st rlen ( argv 13 ]  ) +  1  ]  ; 
strcpy (aName, argv [ 3 ) ) ; 

Dname=  new  char[strlen(argv(4])+l]; 
strcpy (Dname, argv [ 4 ] ) ; 
sprint f(datel,"%s  %s", aName , Dname ) ; 
getSchedule_l (dbName,  1 istName, date! ) ; 

) 

else  i£{option[0]  ==  ■7'){ 

aName  =  new  char (strlen (argv [ 3 1 ) +1 1 ; 
strcpy (aName, argv ( 3 ) ) ; 
update_start_t ime (dbName, 

list Name, aName) ; 

) 


) 


5.  Class  Time 

support_classes.h  ••••••*•••*•••••• 

#ifndef  _ SUPPORT_CLASSES_H 

#define  _ SUPPORT_CLASSES_H 


class  Time{ 
private : 


unsigned 

priv_minuteInHour 

:11; 

unsigned 

priv_hourlnDay 

:5; 

unsigned 

p  r i v_day I nMon  t  h 

:5; 

unsigned 

priv_monthInYear 

:4; 

unsigned 

pr i v_y ea  rFroml 993 

:5; 

public : 

Time (  int  min,  int  hour,  int  day,  int  month,  int  year  ) ; 
Tim.elchar*  dateTimeString)  ; 

Time (  APL*  theAPL) ; 

Time  operator+ (  int  duration  ) ; 
int  operator- (Time&  anotherTime) ; 

OC_Boolean  operator== (  Timei  anotherTime  ) ; 
OC_Boolean  operator>(  Time&  anotherTime  ); 
char*  makeString(  ); 
void  display ( ) ; 


#endif  // _ SUPPORT_CLASSES  H 
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suppori_classes.cxx 


t»include  --Type.h^ 

(♦include  <Ob]ect.h> 

((include  <Globa  1  Ent  if.  les  .  h  > 
♦(include  <Database.h> 
#include  <Directory . h> 
#include  <stream.h-> 
extern  “C“ 

{ 

(♦include  <strings.h> 
iinciude  <ctype.h-'- 
#include  <stddef.h' 

(♦include  vstring.h' 

} 

#ifndef  _ SUPPORT_CLASSES_H 

#include  “ support_classes . h" 
(♦endi  f 


//  Init  nuIlTine 

static  Time  nul iTime ( 0 , 0 , 0 , 0, 0 )  ; 

//  Constructor  used  for  ♦  operation,  just  initialize  tields 
Time:;Time(  int  min,  int  hour,  int  day,  int  month,  int  year  ) 
priv_minuteInHour (  min  ),  priv_hour InDay  (  hour), 
priv_dayInMonth  (  day  ),  priv_monthInYear (  month  ), 
priv_yearFroml993 (  year  ) 

{ 

) 


//  Activation  Constructor 
Time  ::Time(APL*) 

{ 

} 

//  Constructor  used  by  end  user,  converts  standard 
//  mm/dd/yy  hh; 

mm  format  to  internal  representation 
Time::Time(  char*  dateTimeString  ) 

{ 

int  month,  day,  year,  hour,  minute; 


Si  day , 


sscanf (  dateTimeString,  "%d/id/%d  %d:%d",  &month, 

Siyear , 
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&hour , iminute)  ; 

priv_ye'irFroml  99  3 
pr i v_mont  hInYear 
priv_daYlnMonth 
pr  iv_hour  InDav' 
pr iv_minut F '  Hour 


=  yea  r -  9  3 ; 
=  iT’.oiith; 

=  day  ; 

=  hour; 

=  minute; 


//  Adds  duration  to  t;ie  hourlnPay  field. 
Time  Time: 


operator*'  int  duratio»i  ) 

{ 

//  unsigned  ti,  t2,  t3,  t 3 , t 5 ; 

int  tl,  t2,  t3,  t4,t5; 

t4  =  pr iv_hour InDay ; 

t4  =  t4*duration; 

tl=t4; 

pri v_hour InDay=t  4 ; 
if  (t4  >  16)  { 

t4  =  (t4-16)%8  *  8; 
priv_hourInDay  =  t  4 ; 


t5=priv_dayInMonth; 
t5  =  (t5  *1*  (tl-16) /8) ; 
priv_dayInMonth  =  t  5 ; 
if  (t5  >  30) { 

r5=  t5-  30; 
priv_dayInMonth=t5 ; 

t3=priv_monthInYear  ; 
t3=  t3+l  ; 

priv_monthInYear  =  t  3 ; 
if  (t3>12)( 

t3=t3-12; 
priv_rnor'a  t'.InVe.ii  - 


1 2  =pr 1 v_yearFroml 99  3  ; 


t2=t2*  L ; 


priv_yearFroml993=t2  ; 

) 

) 

} 

Time  result!  priv_minuteInHour , priv_hour InDay , 
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priv_claylnMonth,priv_mor.hInYear,priv_yearFroml993  )  ; 
return  result; 

) 

//  subtract  two  .imes  resturning  the  difference  in  hours, 
int  Time ;  : operutor- (Timeic  my^time  ) 

{ 

int  result; 

int  month,  day,  year,  hour; 
hour=priv_hourInDay-rny_t  ime  .  pr iv_hourInDay  ; 
days  priv_dayInMonth-my_time .priv_dayInMonth; 
mo^th=  priv_monthInYear-my_time .priv_monthlnYear ; 
y,2ar=priv_yearFroml993-my_time  .priv_yearFroml993  ; 

resultshour+ (day*8) + (month*240) + (year*12*240 ) ; 
return  result; 

) 


OC_Boolean  Time :: operator s= (  Time&  anotherTime  ) 

{ 

return  (OC^Boolean)  (* (int*) this  s* 

* ( int  * ) &anotherTime ) ; 

} 

OC_Boolean  Time: :operator>(  Timei  anotherTime  ) 

{ 

if  (priv_yearFroml993  >  anotherTime. priv^earFroml993 ) 
return  TRUE; 
eise{ 

if (priv_yearFroml993  =s  anotherTime .priv^yearFroml 9 93 

&& 

priv_inonthInYear  >  anotherTime. priv_monthInYear) 
return  TRUE; 
else{ 

if (priv_yearFroml993==anotherTime.priv _yearFroml993  && 

priv_monthInYear  == 
anotherTime .priv_monthInYear  it 

priv_dayInMonth  >  anotherTime .priv_daylnMonth) 
return  TRUE; 
else{ 

if (priv_yearFroml993  s= 

anotherTime. priv_yearFroml993  && 
priv^monthlnYear  s= 
anotherTime. priv_monthInYear  && 
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priv_dayInMonth  == 
anotherTime .priv_dayInMonth  && 
priv_hourInDay  > 
anotherTime . pr i v^hour InDay ) 

return  TRUE; 
else{ 

if (priv_yearFroml993  == 

anotherTime. priv_yearFroml993  && 
priv_monthInYear  == 
anotherTime .priv_monthInYear  && 
priv_dayInMonth  == 
anotherTime. priv_dayInMonth  && 
priv_hourInDay  == 
anotherTime. priv_hourInDay  && 
priv_minuteInHour  > 

anotherTime . priv_minut eInHour ) 
return  TRUE; 
else 


} 


return  FALSE; 


char*  Time: rmakeString (  ) 


{ 

char  result!  16  ); 
sprint f (result . •% .2d/% . 2d/% . 2d 
%.2d:%.2d" , priv_monthInYear,  priv_dayInMonth, 

priv_yearFroml993+93 ,  priv_hourInDay 
priv_minuteInHour  ) ; 

return  (strdup  (result)); 


) 


void  Time::  displayO 
{ 

printf  ("  %d/%d/%d  %d:%d  ■,  priv_monthInYear , 

priv_dayInMonth, priv _yearFroml993 ,  priv_hourInDay 


} 


priv_minuteInHour  ) ; 


My  String.h  ************************************************************ 
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iifndef  _My_String_H 
#define  _My_String_H 

#include  <iostream.h> 


#include  <stdio.h> 

#include  <string.h> 

class  My_String_rep 
{ 

char*  str; 
int  refs; 

int  length;  //  does  not  include  null  byte 
My_String_rep(char  *); 

My_String_rep (char  •*)  ; 
friend  class  My_String; 

}; 


class  My_String 

{ 

My_String_rep  *r; 

My_String (char**) ; 

public : 

My_String(My_String&) ; 

My_String (char*  =  "*); 

-My_String( ) ; 

My_String&  operators  (My_String)  ; 

operator  char  * { )  ; 

const  char*  stringO; 

int  Scr_length( ) ; 

void  print ( ) ; 

friend  int  operator  <  (My^String,  My_String) ; 
riend  int  operator  >  (My_String,  My_String) ; 
friend  int  operator  s=  (My_String,  r^_String) ; 
friend  int  operator  !=  (My_String,  My_String) ; 
friend  My_String  operator+  (My_String,  My_String) 
friend  My_String  operator-  (My_String,  My_String) 
friend  My_String  operator-  (My_String,  int); 
friend  ostreami  operator<<  (ostreami,  My_String) 
friend  istream&  operator>>  (istreami,  My_String&) 


tend if  _My_String_H 
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My_String.cxx 

#include  "My_String .h" 

My_String_rep: :My_String_rep (char  *s) 

{ 

str  =  new  char[  (length  =  strlen(s))  1]; 
strcpyistr,  s) ; 
refs  =  1; 

} 

My_String_rep ; :My_String_rep (char**  ptrptr) 

{  ” 

str  =  *ptrptr; 
refs  =  1; 

length  =  strlen(str); 

) 

My_String: :My_String (char  *s) 

{ 

r  =  new  My_String_rep (s) ; 

} 


My_String: ;My_String (char**  ptrptr) 

{ 

r  *  new  My_String_rep (ptrptr) ; 

} 

My_String: :My_String (My_String  &init) 

{ 

r  =  init.r; 
r  ->refs++; 

) 

My_String&  My_String: : operator* (My_String  str) 

{ 

if  ( ! --r->refs) 

{ 

delete  r->str; 
delete  r; 

} 

r  =  str.r; 
r  ->  refs++; 
return  *this; 

) 


290 


My_String: : -My_String ( ) 

( 

if  (J--r->refs) 

{ 

delete  r->str; 
delete  r; 

} 

} 

My_String: : operator  char*  () 

{ 

char  *p  =  new  char [ (r->length)  +  1] ; 
strcpy (p, r->str) ; 
return  p; 

} 

const  char*  My^String: : string () 

{ 

return  (r->str) ; 

} 

int  operator<  (My_String  si,  My_String  s2) 

return  ( strcmp (si .string (> ,  s2. string!)  )  <  0  ) 

} 

int  operator>  (My_String  si,  My_String  s2) 

return  (  strcmp (si .string () ,  s2. string!)  )  >  0  ) 

} 

int  operators* (My^String  si,  My_String  s2) 

return  (  strcmp  (  si. string!),  s2. string!)  )  ==  0 

) 

int  operator!* (My ^String  si,  My_String  s2) 

{ 

return!  strcmp  !  si. string!),  s2. string!)  )  !=  0 

} 

ostream&  operator«  (ostream&  o,  My_String  si) 

{ 

o  «  si. string!)  ; 
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( 

f 

return  o; 

} 

istreami  operator>>  (istreain&  o,  My_Stringi  s2) 

{ 

char  buf [256] ; 
o  »  buf; 

s2  =  My^String (buf ) ; 
return  o; 

} 


int  My_String: :Str_length( ) 

{ 

return  (  r->length  ) ; 

) 

void  My_String :: print ( ) 

{ 

printf(‘%s',  stringO  ); 

} 


/*  My_String  operator+  (My_String  si,  My_String  s2) 

( 

char  't; 

t  a  new  char [si .Str_length( )  +  s2 . Str_length( )  +  1) ; 
strcpy (t, si . string ( ) ) ; 

My_String  s3 (strcat (t, s2 . string ( )  )  ) ; 
delete  t; 
return  s3 ; 

}  V 


My.String  operator+  {My.Strins^  si,  My.String  32) 

{ 

char  *t; 

t  =  new  charfsl  .Str^lengthO  +  s2  .  Str_length  ( )  + 

11  ; 

strcpy  (t,  si. StringO  )  ; 
strcat (t , s2 .string ( ) ) ; 

My_String  s3(&t); 
return  s3 ; 

) 
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4; 


My_String  operator-  (My_String  si,  My_String  s2)  ( 
char*  t; 

int  n  =  si . Str_length ( )  -  2*s2 . Str_length ( )  - 
t  =  new  char[n  +  11; 
char*  p; 

strncpy(t,  p  s  (char*)sl.  n) ; 
t[n]  =  -XO*; 

My_String  s3(&t); 
deleted  p; 
return  s3; 

} 

My_String  operator-  (My_String  si,  int  n)  ( 
char*  t; 

int  k  =  si . Str_length ( ) -  n  ; 
t  =  new  chartk+1]; 
char*  p; 

strncpy(t,  p  =  (char*) si,  k) ; 
tlk]  =  -\0‘; 

My_String  s3(&t); 
delete []  p; 
return  s3 ; 

} 


C.  PROGRAMS 

There  are  two  main  Ada  packages  in  addition  to  the  main  programs  for  the  manager 
interface,  designer  interface  and  the  Tae  program  on  top  of  the  manager  interface.  The  two 
main  packages  are  the  Ada  interface  to  C-m-  package  that  enables  the  Ada  programs  to 
access  the  data  in  the  design  database  and  .  ,e  scheduler  package  that  implements  the 
scheduling  algorithm.  In  the  rest  of  this  section  we  include  a  copy  of  the  Ada  code  for  both 
the  specification  and  the  implementation  of  both  packages  in  addition  to  the  code  for  the 
other  main  programs.  The  module  dependency  diagram  for  the  relations  between  different 
program  modules  is  shown  in  Figure  32. 

1.  The  Ada  Interface  to  DDB  Package 
ECS_Operations_s,a 

--  Title  :  The  scheduler  spec  package 

--  Author  :  Salah  badr 

--  Date  :  4  Sept  1993 
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Manager  Interface 
Tae  Interface 


FIGURE  32.  ECS  Module  dependency  diagram 
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Suns7 

verdixAda 


--  Revised 
--  System 
--  Compiler 
--  Description 

with  TEXT_IO;  --  BASIC_NUM_IO; 
use  TEXT_IO;  BASIC_NUM_IO  ; 

with  scheduler;  use  scheduler; 

generic 

package  ECS_OPERATIONS  is 

package  nat_io  is  new  integer_io (natural ) ;  use  nat_io; 
procedure  system_call (command  rstring) ; 


procedure  auto_mail (name  :  string; 

step_id  :  string) ; 

procedure  auto_mail2 (name  :  string; 

step_id  ;  string) ; 

procedure  auto_mail3 (name  :  string; 

step_id  :  string) ; 


COMPONENET  OPERATIONS 


procedure  Create_Prototype (ddbname  : string ; 

option  : St ring; 

protoname  :string); 

procedure  Show_Prototypes  (ddbname  .-string; 

option  :string) ; 

--  This  function  is  general  for  all  the  operations:  Show 
--  Component , Show  SubTree,  Add  New  Version,  Dump 
--  Component, and  Dump  SubTree  The  only  difference  is  the 
--  option  number 


procedure  general_function (ddbname  : string ; 

option  : string: 
protoname  rstring; 
varver  : string; 


comp_name  ; s  t  r i ng ) ; 


procedure  Add_SubComponenc (ddbname 

option 

protoname 

var_ver 

comp_name 

varl_verl 

parent 


: string; 

; string; 

:  string; 

: string; 

: string; 

: string; 

: string) ; 


procedure  Dump_ver si on (ddbname 

option 

protoname 

comp_name 

varl_verl 


; string; 

: string; 

: string; 

: string; 

: string) ; 


STEP  OPERATIONS 


procedure  Create_Step (ddbname 

option 

proto 

comp 


: string; 

: string; 

: string; 

: string) ; 


--  this  function  show  either  one  step  or  a  set  of  steps 
--  according  to  the  option  given, 
procedure  Show_Step (ddbname  : string; 

option  : string; 

step_id  :string); 


procedure  get_sched_data (ddbname  .-string; 

step^id  istring); 

procedure  get_sched_data_2 (ddbname  : string; 

d_name  : string) ; 

--  This  function  is  general  for  all  the  operations:  delete 
--  input  (primary,  secondary  or  affected  modules),  updating 
--  precedence, priority ,  exp_level  duration,  status  or 
--  designer's  name.  The  only  difference  is  the  option  number 


procedure  general_update (ddbname  : string ; 

option  : string; 

step_id  : string; 
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value 


:  String) ; 


procedure  create_substep (ddbname  : string; 

option  : string; 

step_id  : string ; 

p_input  : string; 

duration  istring); 

--  This  function  does  add  step  inputs  primary,  secondary  or 

--  affected  modules.  The  only  difference  is  the  option  number 

procedure  update_time (ddbname  : string; 

option  : string; 

step_id  ; string; 

the_time  -.string); 

procedure  remove_Sv.ep_from_schedule (ddbname 

option 
step_id 
theDate 

procedure  Early_Warning (ddbname  : string; 

option  : string; 

manager  :string); 

__*»•******■»*•***«*****»*«**•*******♦•*■***»***»*»*»♦»*****•** 

SCHEDULE  OPERATIONS  • 

__*••*****•*•***•***•*•»«♦*♦***■***»*****»****•*»**♦»»******» 

procedure  Add_Assignment (ddbname  :string; 

option  : string ; 

step_id  : string; 

desname  : string; 

the_time  : string; 

start  : string; 

finish  : string ); 

procedure  get_current_time (the_time :out  string); 

procedure  Show_Schedule (ddbname : string; 

option  .-string); 

procedure  get_sched_data_l  (ddbname  .-string; 

d_name  : string)  ,- 

procedure  Get^Schedule ( ddbname : string ; 

option  .-string)  ; 


:  string; 

; string ; 

:  string; 

:  string) ; 
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procedure  Delete_Assignment (ddbname : string ; 

option  :  string; 
step_id: string) ; 


procedure  Delete_Schedule (ddbnaine : string ; 

option  .-string); 

procedure  SAVE.SCHEDULE ( HEAD  :  in  LINKl ; 

dbname:  string; 
d_vector:  in  vector; 
my_list  :  D_LINK  ) ; 

procedure  MAIN ( indicator :  in  integer); 


DEASIGNER  POOL  OPERATIONS 


procedure  DESIGNER_MENU; 
procedure  DESIGNER_OPERATIONS; 


procedure  Add_,designer  (ddbname :  string; 

option  : string; 
desname: string; 
level  :string); 

procedure  Show_designer (ddbname: string ; 

option  : string) ; 

procedure  put_designers ( ddbname: string ; 

option  :string); 

procedure  Delete_designer ( ddbname : string ; 

option  :string; 
desname: string) ; 

procedure  Change_exp_level (ddbname: string; 

option  : string ; 
desname : string ; 
level  : string); 

procedure  Change_status (ddbname: string; 

option  :string; 
desname: St ring) ; 

end  ECS_OPERATIONS ; 
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ECS_Operations_b.a 

--  Title 
--  Author 
--  Date 
--  Revised 
--  System 
--  Compiler 
--  Description 


Scheduler  package  body 
Salah  badr 
4  Sept  1993 

Suns7 

VerdixAda 


with  text_io,  system; 

use  text_io,  system; 

with  scheduler;  use  scheduler; 


package  body  ECS 
Namel 
option 
Name  3 
Name4 
Names 
Names 
Name7 
D_status 
SELECTOR 
Length 
Lengthl 

data_file  : 

answer  ; 

procedure  system. 


.OPERATIONS  is 
STRING ( 1 .  .  9 ) 
STRINGd  .  .1) 
STRING ( 1 . . 64 ) 
STRINGd  .  ,64) 
STRINGd  .  .64) 
STRINGd.  .64) 
STRINGd  .  .64) 
STRINGd  .  .4)  ; 
natural  :=  0; 
integer; 

:  integer; 
FILE_TYPE; 
character  :=' 
.call (command 


=  *supportDB“; 


y  ; 

:string)  is 


procedure  system_C (command  : address ) ; 
pragma  INTERFACE (C,  system_C) ; 
pragma  INTERFACE_NAME(system_C,  ’^system'); 
temp  :  constant  STRING  :=  command&ASCII .NUL; 
error:  integer; 

begin 

system_C( TEMP -ADDRESS) ; 
end  system_call; 


procedure  auto_maii (name  :  string; 

step_id  :  string) is 

begin 

CREATE (data_file,  OUT_FILE, -tempZ") ; 

put (data_f ile, "You  have  been  assigned  the  step  no:  " ) ; 
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put (data_£ile, step_id) ; 

CLOSE (data_f lie)  ; 

sy3tem_call  ( “mail  “&name&“<  teiTip2‘); 
syst em_ral 1 ( • rm  temp2"); 
end  auto_mail; 


procedure  auto_maill (name  :  string; 

step_id  ;  string) is 

begin 

CREATE (data_file,  OUT_FILE, •temp2 * ) ; 

put (data_file, ‘ATTENTION  REQUIRED  Step:  " ) ; 

put {data_£ile, step_id) ; 

put {data_f ile, *  should  commit  within  an  hour...“); 
CLOSE(data_f lie) ; 

system_call { "mail  "&name&“<  temp2‘); 
system_call ( "rm  temp2“); 
end  auto_maill; 


procedure  auto_mail2 (name  :  string; 

step_id  :  string) is 

begin 

CREATE (data_f ile,  OUT_FILE, "temp2* ) ; 

put (data_f ile, "Your  current  assigned  step:  "); 

put (data_f ile, step_id) ; 

put (data_£ile, *  has  been  Suspended...*); 

CLOSE (data_f ile) ; 

system_call ( "mail  “&name&*<  temp2“); 
system_call ( "rm  temp2*); 
end  auto_mail2; 


procedure  auto_iriail3  (name  :  string; 

step^id  :  string) is 

begin 

CREATE (data_£ ile,  OUT_FILE, "temp2‘) ; 

put (data_f ile, "Your  current  assigned  step:  " ) ; 

put (data_f ile, step_id) ; 

put (data_f ile, ■  has  been  abandoned..."); 

CLOSE (data_f ile) ; 

system_call ( "mail  "&name&*<  temp2"); 
systeni_call  ( "  rm  temp2"); 
end  auto_mail3; 


COMPONENT  OPERATIONS 
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procedure  Create_Prototype {ddbname 

option 

protoname 


:  string; 
••string; 
istring)  is 


begin 


system_call  ( "maincomp  *•&“  *&ddbnamef  ■ioption&" 
•Siprctoname)  ; 
end  Create_Prototype; 


procedure  Show_Prototypes (ddbname 

option 

: string; 

:string)  is 

begin 

system_call ( "maincomp  "&"  *&ddbname&"  *&option&"  > 
ddbdisplay" ) ; 
end  Show_Prototypes ; 

--  This  function  is  general  for  all  the  operations:  Show 
--  Component , Show  SubTree,  Add  New  Version,  Dump  Component, 
--  and  Dump  SubTree  The  only  difference  is  the  option  number 

procedure  general^function (ddbname 

option 

protoname 

var^ver 

comp_name 

: string ; 

:string; 

: string; 

: string ; 

:string)  is 

begin 

system_call ( "maincomp  *&ddbname&*  " 
■&var_ver&"  •&comp_name) ; 
end  general_f unction; 

&option&'  "Stprotonamei" 

procedure  Add_SubComponent (ddbname 

option 

protoname 

var_ver 

comp_name 

varl_verl 

parent 

:  string; 

: string; 

; string; 

.•string; 

: string; 

: string; 

:string)  is 

begin 

system_call ( "maincomp  "&*  *&ddbname&"  "&option&" 
"&protoname&"  " 

&var_ver&"  "&comp_name& *  "&varl_verl&" 

"iparent ) ; 

end  Add_SubComponent ; 
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procedure  Dump_version (ddbname  : string, • 

option  : string; 

protoname  : string; 
comp^name  : s  t  r i ng ; 
varl_verl  : string)  is 

begin 

systen\_call  ( "ma incomp  ■*&"  *&ddbname&"  •&option&" 
*&protoname&"  • 

&comp_name&*  *&varl_verl )  ; 
end  Dump_version; 


STEP  OPERATIONS 


--  option  (1) 

procedure  Create_Step (ddbname  : string; 

option  : string; 

proto  : string; 

comp  : string)  is 


begin 

system_call  ( “mainstep  “&•  “&ddbname&''  •&optionfit-  ■•&proto&* 
"&comp) ; 

end  Create_Step; 

--  this  function  show  either  one  step (2)  or  a  set  of  steps  (3) 
—  according  to  the  option  given. Same  function  is  used  for 
--  commit_step (e) ,  approve(c),  and  commit_substep (d) 

procedure  Show_Step (ddbname  rstring; 

option  : St ring; 

step_id  .-string)  is 

begin 

system_call ( "mainstep  “&ddbname&"  •&option&“ 
■istep_id&*  >  ddbdisplay" ) ; 
end  Show_Step; 

--  This  function  is  general  for  all  the  operations: 

--  status(7)  or  designer's  name(8) , 

--  The  only  difference  is  the  option  number 


procedure  general_update (ddbname  : string; 

option  : string; 

step_id  : string; 


value 


istring)  is 


begin 

system_call ( 'mainstep  “i*  ‘&ddbname&“  •&option&“ 
■•&step_id&''  ‘&value)  ; 
end  genera l^update; 


procedure  create_substep (ddbname  : string ; 

option  : string; 

step_id  : string; 

p_input  : string ; 

duration  : string)  is 

the_time : string (1 . . 14 ) ; 

begin 

get_current_t ime ( the_t ime ) ; 

systein_call  { "ma instep  "&ddbnairei"  "&option&“ 
*&step_id&"  “&p_input&"  " 

&the_time&*  ‘&duration&"  >teinp8*); 
end  create_substep; 


--  option  (a) 

procedure  get_sched_data (ddbname  : string; 

step_id  :string)is 
the_tiine:string(l.  .14)  ; 

begin 

get_current_time(the_time) ; 

system_call ( “mainstep  "&■  ‘fitddbname&“  a  "&step_id&* 

"  &the_t  ime& "  >teinps  “ )  ; 
end  get_sched_data; 

--  option  (i) 

procedure  get_sched_data_2 (ddbname  : string; 

d_naine  :string)is 

the_t ime: string (1 . .14)  ; 

begin 

get_current_t ime ( the_t ime ) ; 

system_call  ( "mainstep  "S*  "&ddbname&*  1  ■&the_timeSt“ 

*  &d_name& "  >t  emps ■ ) ; 
end  get_sched_data_2 ; 

--  This  function  updates  start_time(5) ,  and  f inish_time ( 6) 
procedure  update^time (ddbname  ; string ; 

option  : string; 

step_id  : string ; 
the_time  ; string)  is 


303 
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begin 

system_call  ( ‘mainstep  •&“  ■  &ddbnaineSt “  •Sioption&“ 
*tstep_id&"  * 

Set  bedtime)  ; 

end  update_tiine; 


--  optionsf 

procedure  reinove_step_froni_schedule (ddbname  ; string; 

option  : string; 

step_id 


: St ring; 

theDate  : string) 

begin 

systen\_call  ( “mainstep  “fitddbnameSit*  “ioptionSe* 
“&step_id&*  “&theDate&“  >temp4“); 
end  remove_step_from_schedule; 


is 


--  optionsk 

procedure  Early_Warning  (ddbn2une 

option 

manager 

: string (1 . .14) ; 
:string(l . .5); 

: string (1. ,64) ; 

:  FILE_TYPE; 


:  string ; 
: string; 
.•string) 


IS 


the_time 
an_id 
Name4 

data_filel 
begin 

get_current_time ( the_time) 
system_call { “mainstep  “&* 
“&the_time&“  >temp6"); 

OPEN(data_filel,  IN_FILE, “tempS") ; 
WHILE  not  END_OF_FILE(data_filel) 
get_line {data_f ilel , an_id, length) ; 
for  i  in  Length+1 . . 5  loop 
an^id ( i ) : = '  ' ; 
end  loop; 

get_l ine ( dat a_f i 1 el , Name4 , 1 ength ) 
for  i  in  Length+1.. 64  loop 
Name4 ( i ) : = '  ' ; 
end  loop; 

auto_maill (Name4 , an_id) ; 
auto_maill (manager, an_id) ; 
end  loop; 

CLOSE ( da ta_fi lei) ; 
system_call ( “rm  temp6"); 
end  Early_Warning; 


&ddbname& "  “ &opt ion& ' 


loop 
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SCHEDULE  OPERATIONS 


procedure  Add_Assigrm\ent  (ddbname 

option 

step_id 

desname 

the_time 

start 

finish 


: String; 

: string; 

: string; 

: string; 

: string ; 
:string; 
:string)  is 


begin 

system_call  ( "mainsched  •&ddbnaine&“  “Stoptioni" 
"&step_id&'  ''&desname&"  “ 

&the_tiine&*  "&start&*  *&finish)  ; 
end  Add^Assignment ; 


procedure  get_current_tin\e(the^tiine:out  string)  is 
begin 

system_call ( "date  '+%m/%d/%y  >  tempi"); 

OPEN|data_file,  IN_FILE, "tempi") ; 
get (data_f ile, the_time) ; 

CLOSE (data_file) ; 
system_call ( “rm  tempi"); 
end  get_current_time; 

.^«*««**«**««**********«*****'lr**'**««**********»************* 

—  option  =  1 

procedure  Show_Schedule (ddbname : string; 

option  : string)  is 

begin 

system_call ( "mainsched  "&ddbname&"  "&option&" 

>ddbdi splay" ) ; 
end  Show_Schedule; 

procad-.’re  get_sched_data_l  (ddbname  : string; 

d_name  : string)  is 

the_time : string ( 1 . . 14 ) ; 

begin 

get_current_time{the_time)  ; 

system_call ( "mainstep  "&*  "&ddbname&"  m  "&the_time&" 

" &d_name& "  >temp3 " ) ; 
end  get_sched_data_l ; 


--  option  =  5 
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procedure  Get_Schedule (ddbname : string; 

option  : string)  is 

begin 

system_call ( "mainsched  *&“  •&ddbname&"  ‘&option) ; 
end  Get_Schedule; 


--option  =4 

procedure  Delete_Assigninent  {ddbnaire:  string; 

option  : string ; 
step^id: string)  is 

begin 

systein_call  ( ‘■mainsched  •  &ddbname& *  “&option&“ 

“&step_id) ; 

end  Delete_Assigninent ; 


--  option  =  3 

procedure  Deiete^Schedu) e (ddbname : string; 

option  : string)  is 

begin 

system_call  ( *nvainsched  “&ddbname&*  "fcoption) ; 

end  Delete_Schedule; 

__**•*******★*********★**♦******************•************■**** 

--*  DESIGNER  POOL  OPERATIONS  * 

__«***♦**************•********************«*****************• 

procedure  Add_designer (ddbname : string ; 

option  : string; 
desname : string ; 
level  : string)  is 

begin 

system_call  ( "maindes  *&"  •&ddbname&“  "&optionSt“ 
"&desname&''  “StleveD; 
end  Add_designer; 

__**********■*********************•*»******************»***** 

procedure  Show^designer (ddbname : string; 

option  : string)  is 

begin 

system_call ( "maindes  *&"  *&ddbname&"  "&option&"  > 
ddbdisplay" ) ; 
end  Show_designer; 

_ *********************************************************** 

procedure  put_designers ( ddbname: string; 

option  : string)  is 

begin 

system_call  ( "maindes  "Stddbname&*  "&option&"  >temp2"); 

end  put_designers ; 

_ ********************************************************** 
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procedure  Delete_designer (ddbname : string ; 

option  :string; 
desname: string)  is 

begin 

systein_call  ( "maindes  •&ddbnamef  3  “idesname)  ; 
end  Delete_designer; 


procedure  Change_exp^level  {ddbname .-string; 

option  -.string; 
desname: scring; 
level  : string)  is 

begin 

system_call ( “maindes  “&ddbname&“  4  “&desname&" 

“&level) ; 

end  Change_exp_level ; 


procedure  Change_status (ddbname: string ; 

option  :string; 
desname: string)  is 

begin 

system_call  ( "maindes  "&*  "&ddbname&"  5  “idesname)  ,- 
end  Change_status; 


--  DISPLAY  THE  MAIN  MENU, 
procedure  DESIGNER_MENU  is 
begin 

new_line; 

set_col(25) ;  put (“MAIN  MENU");  new_line; 

set_col(25);  put(“ - “);  new_line(2)  ; 

set_col(5);  put{"[l)  Add  designer" ); 
new_line; 

set_col(5);  put ("(2)  Show  designers") ; 
new_line; 

set_col(5);  put(*(3]  Delete  designer") ; 
new_line; 

set_col(5);  put ("(41  Change  expertise  level" ); 
new_line; 

set_col(5);  put ("[5]  Return  to  main  menu"); 
new_line (3 ) ; 

set_col{5);  put ("Enter  the  number  of  your  choice 
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end  DESIGNER.MENU  ; 


procedure  DESIGNER_OPERATIONS  is 
begin 

loop 

DESIGNER_MENU  ; 

get (SELECTOR) ;  skip_line  ; 
case  SELECTOR  is 

--  insert  a  record  into  database, 
when  1  => 

option ; 

while  answer  =  ‘y*  or  answer='Y‘  loop 
put ("Enter  designer’s  name:  "); 
get_line (Name3 , Length) ; 
for  i  in  Length+1..64  loop 
Neune3  ( i )  :  =  *  '  ; 
end  loop; 

put ("Enter  Expertise  Level:  "); 
get_line(Name4, Length) ; 
for  i  in  Length+1..64  loop 
Name4 ( i ) : = ’  ' ; 
end  loop; 

Add_designer (Namel , option, Name3 , Name4 ) ; 
put ("Add  more  designers  (Answer  y/nj :  "); 
get  (answer)  ;  s)cip_line  ; 
end  loop; 

put_designers (Namel,  "2"); 
get_sched_data (Namel , " 0 " ) ; 
get_sched_data_l (Namel , Name3 ) ; 
main(O) ; 

when  2  =>  --  Show  designers 

option :="2" ; 

Show_designer (Namel, option) ; 
when  3  *>  --  Delete  designer 

option:="3" ; 

put ("Enter  designer's  name:  " ) ; 
get_line (Name3 , Length) ; 
for  i  in  Length+1.,64  loop 
Name3 ( i ) ; » ‘  ’ ; 
end  loop; 

Show^designer (Namel ,"2"); 

OPEN(data_file,  IN^FILE, "ddbdisplay" ) ; 
WHILE  not  END_OF_FILE(data_file)  loop 
get_line(data_file,Name4,  lengthl)  ,- 
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for  i  in  Lengthl+1 . . 64  loop 
Naine4  ( i )  :  =  '  *  ; 
end  loop; 

put^line (Name4 { 1 . . length) )  ; 

put_line (Name4 (45 . . 48 ) ) ; 

if  Name4  (1 .  .  length)  =Naine3  ( 1 .  .  length) 

then  D_status :  =Naine4  (45  .  .  48 )  ; 

end  if; 

end  loop; 

CLOSE (data^file) ; 
systein_call  ( *rm  ddbdisplay" )  ; 
if  D_status(l. .4) =  "Busy*  then 
put_line( “Desiner  is  busy,  Confirmation 

Required" ) ; 

put  ( "Do  you  have  to  delete  him  now(answer 

y/n) :  " ) ; 

get  (answer);  SK.ip_line; 
if  answer  a'y*  or  answer  =  'Y'  then 
Delete_designer (Namel , option, Name3 ) ; 
system^call  ( "mainsched  *&NamelSc"  7 

• &Name3 ) ; 

put_designers (Namel , "2  * ) ; 
get_sched_data (Namel  ,"0"); 
get_sched_data_l (Namel , Name3 ) ; 
main(O) ; 
end  if; 
else 

Delete_designer (Namel , option, Name3 ) ; 
end  if; 

when  4  =>  --  Change  expertise  level 

option:=:"4" ; 

put{"Enter  designer's  name:  "); 
get.line(Name3, Length) ; 
for  i  in  Length+1..64  loop 
Names ( i ) : » '  ' ; 
end  loop; 

put ("Enter  Expertise  Level:  "); 
get_line (Name4 , Length) ; 
for  i  in  Length+l . . 64  loop 
Name4 ( i ) : = '  ' ; 
end  loop; 

Change_exp_level (Namel , option , Name3 , Name4 ) ; 
put_designers  (Nc-Tiel,  "2")  ; 
get_sched_data (Namel , *0 " ) ; 
get_sched_data_l (Namel , Name3 ) ; 
main(O) ; 
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when  5  => 

put ("thank  you  ....  Bye  ...Bye“); 
new_line  ; 
exit ; 

--  exception  handling  for  selector  case, 
when  others  => 

putC  BAD  CHOICE.  PLEASE  TRY  AGAIN"); 
new^line  ; 
end  case; 
end  loop; 

end  DESIGNER_OPERATIONS; 


procedure  SAVE_SCHEDULE  (HEAD  :  in  LINKl; 

dbname  :  string; 
d_vector:  :;n  vector; 
iny_list  :  D_L1NK  )  is 
CURRENT  :  LINKl  :=  HEAD  ; 
nty_time:  string  (1 . .  14)  ; 
an_id  : string ( 1 . . 3 ) ; 
start  ;string(l. .3) ; 
finish  :string(l. .3) ; 

designer  : string (1. .64) ; 
iny_naine  :  string  (1 ..  16) ; 
my^index:  natural; 
length  ;  natural; 

begin 

get_current_time  (nTy_tiine)  ; 
while  CURRENT  /=  null  loop 

put (an_id, CURRENT. STEP_ID) ; 
put ( start , CURRENT . START_TIME ) ; 
put (finish,  CURRENT. FINI SH_TIME ) ; 
if  CURRENT. DESIGNER_LEVEL  =  high  then 
niy_index  :»  CURRENT. DES I GNER_NO  + 

d_vector ( 1 ) +d_vector ( 2 ) ; 
elsif  CURRENT. DES IGNER_LEVEL  =  medium  then 

my_index  :=  CURRENT.  DES  I  GNER_NO  +  d_vectorC); 

else 

my_index  :=  CURRENT. DESIGNER_NO  ; 
end  if; 

FIND_DESIGNER(my_list,  my_index,  my_name) ; 

if  CURRENT. START_TIME  =  0 

then  auto_mail  (rrr/_name,  an_id)  ; 

Change_status  (Namel , "  5 " .  iny_name )  ; 
general_update(Namel, "7",an_id, "3") ; 
general_update (Namel, " 5" , an_id, my_time) ; 
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else 

generaI_update(Naniel,  ■7“,an_id,  “2")  ; 
end  if; 

general_update (Namel , "8* , an_id,my_name) ; 
Add_Assigninent  (dbname,  "l*,an_id,  my.name, 
iny_time,  start,  finish); 

CURRENT  : =  CURRENT. NEXT  ; 
end  loop; 

end  SAVE_SCHEDULE ; 


procedure  MAIN ( indicator  tin  integer)  is 


an_id 

stringd.  .3)  ; 

STEP.LIST 

LINK  :=  null 

STEP_LIST_TAIL 

LINK  :*  null 

POSITION 

LINK  ; 

PREVIOUS 

LINK  :*  null  ; 

CURRENT 

LINK  ; 

tempi 

LINK; 

SCHEDULE_TAIL 

LINKl  :*  null; 

T,  k,  temp 

natural ; 

S_ID  :  natural;  --  step_id 

R  ;  natural;*  1;  --  row 

C  :  natural:*  1;  --  column 

FOUND  .-boolean  ;=  FALSE; 

FEASIBLE  : boolean  :=  TRUE; 

iny_SELECTOR  ;  natural  :=  0; 

LEVELS  :  natural  :=  3  ; 

READY.LIST:  LI ST_VECTOR ( 1 .. LEVELS) : =  (others  =>  null); 
SCHEDULE  :  SCHEDULE_VECTOR ( 1 . . 5 ) : =  (others  =>  null); 
PENDING.LIST:  link  ;=  null; 

ASSIGNED  :  boolean  :=  TRUE; 
answer  : character  :=*n'; 

level_l,  level_m,  Level^h,  INDEX  :  natural; 

DES^LIST  :  DELINK; 

_ *************************************<r******************** 

begin 

begin 

CREATE_DESIGNER_LIST(DES_LIST, level_l,  level_m, 

Level_h) ; 

if  level_l  >*  level_m  and  level_l  >=  Level_h  then 

INDEX:*  level_l; 

elsif  level_m  >=  level_l  and  level_m  >=  Level_h  then 

INDEX:*  level_m; 

else  INDEX:*  level_h; 
end  if; 
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end; 


DECLARE 

designer_vector  :  VECTOR ( 1 .. 3 )  :=  (level_l,  level_m, 

Level_h) ; 

EAT  :  designer_matrix{l . .LEVELS,  1.. INDEX)  :=  (others 

=>  (others  =>  0)); 


--  Main  program, 
begin 


--  insert  a  record  into  database. 
CREATE_AND_INSERT_NEW_STEP ( STEP_LIST, 

STEP_LIST_TAIL) ; 

if  STEP_LIST  /=  null  then 

RESET_FOR_RESCHEDULING  (DES_LIST, STEP_LIST,  EAT, 

designer_vector ) ; 

k  :=  list_si2e(STEP_LIST) ; 

CURRENT  :=  STEP^LIST; 

while  CURRENT  /=  null  loop  --  initialize  ready_lists 
if  CURRENT. IN_DEGREE  =  0  then 
temp  fiXPERTISE.LEVEL  •  POS  (CURRENT .  EXP_LEVEL)  -1 ; 
INSERT_ORDER_START_TIME ( READY.LI ST ( t  emp ) , 

CURRENT) ; 

CURRENT  : =  CURRENT . NEXT ; 
else 

CURRENT  : *  CURRENT . NEXT ; 
end  if; 
end  loop; 
while  k  /=  0  loop 
for  i  in  reverse  1.. LEVELS  loop 
ASSIGNED  :=  TRUE; 

--  Schedule  the  steps 

while  READY_LIST{i)  /»  null  and  FEASIBLE  and 

ASSIGNED  loop 

STRONGLY_FEASIBLE (READY_LIST ( i ) ,  EAT, 

DESIGNER_VECTOR,  LEVELS,  FEASIBLE) ; 
if  FEASIBLE 
then 

tempi  :=  READY_LIST(i) ; 

LEVEL_MINMUM (EAT,  tempi . EXP_LEVEL, LEVELS, 

DESIGNER_VECTOR ,  R , C ) ; 
ASSIGN_STEP (READY_LIST, STEP_LIST, EAT, 

DESIGNER_VECTOR. R, C, i , SCHEDULE ( 2 ) ,  ASSIGNED) ; 
if  ASSIGNED  then 
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k:=k-l; 

CHECK_IN_DEGREE_1 (tempi,  STEP_LIST, READY_LIST, 

EAT ( R , C ) ) 

end  i f ; 
else  exit; 
end  i f ; 
end  loop; 

if  not  feasible  then  exit;  end  if; 
end  loop; 

if  not  feasible  then  exit;  end  if; 
end  loop; 

SCHEDULE_RECORD_HEADING  ; 

PRINT_ALL_SCHEDULE_RECORDS  ( SCHEDULE (2) , DES_LIST, 

designer_vector) ; 

if  indicator  =  1  then 

put ( "Confirmation  required  to  save  the  schedule  in 

DDE.  Answer (Y/N);  "); 

get (answer) ; 

if  answer  ='y'  or  answer='Y' 
then 

Save_Schedule ( SCHEDULE (2) , NAMEl , 

DESIGNER^VECTOR,  DES_LIST) ; 

end  if; 
else 

Save_Schedule ( SCHEDULE ( 2 ) , NAMEl , 

DESIGNER_VECTOR,  DES_LIST) ; 

end  i f ; 

POSITION  :=  STEP_LIST; 

While  POSITION  /=  null  loop 

if  POSITION. DEADLINE_CHANGE  then 
put (an_id, POSITION. STEP.ID) ; 
system^call ( "mainstep  "iNamel^"  j 
•&an_id) ; 

end  if; 

POSITION  ;=  POSITION. NEXT; 
end  loop; 
end  i f ; 

end; 

end  MAIN; 

end  ECS_OPERATIONS ; 

2.  The  Scheduler  Package 

scheduler_s.a  *•••*••••*•••••••*••♦*♦••••*•*•*•••***••*••*•*•*♦**•♦*••*♦* 

--  Title  :  The  scheduler  spec  package 
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Author 

Date 

Revised 

System 

Compiler 

Description 


Salah  badr 
25  May  1993 

Suns7 
7  dixAda 


with  generic_set_pkg; 
with  generic_map_pkg; 
with  TEXT_IO;  --  BASIC_NUM_IO; 
use  TEXT_IO;  BASIC_NUM_IO  ; 

with  test_io_pkg;  use  test_io_pkg; 


generic 

package  scheduler  is 

package  nat_set  is  new  generic_set_pkg (natural ,  5);  use 
nat_set ; 

--  instantiate  instances  of  the  generic  map  package, 
package  nat_map  is 

new  generic_map_pkg (key  =>  natural,  result  => 

natural ) ; 

package  set_map  is 

new  generic_map_pkg(key  =>  natural,  result  =>  set) 


type  EXPERTISE_LEVEL  is  (low,  medium,  high) ; 
package  exp_map  is 

new  generic_map_pkg (key  =>  natural,  result  => 
EXPERTISE_Lr/EL) ; 


type  STEP_RECORD  ;  --  is  limited  private; 

type  LINK  is  access  STEP_RECORD; 

type  DESIGNER_RECORD;  --  is  limited  private; 
type  D_LINK  is  access  DESIGNER_RECORD; 

type  SCHEDULS_RECORD;  --  is  limited  private; 
type  LINKl  is  access  SCHEDULE_RECORD; 

type  STEP_RECORD  is  record 
NEXT  , 

NEXT_READY, 
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NEXT_PENDING 

LINK; 

STEP_ID 

natural ; 

DEADLINE 

natural  :=  0; 

PRIORITY 

natural ; 

ESTIMATED_DURATION 

natural ; 

EARL I EST_START_TIME 

natural  :-0; 

EXP_LEVEL 

EXPERTISE_LEVEL; 

SUCCESSORS 

set; 

PREDECESSORS 

set; 

IN_DEGREE 

natural ; 

DEADLINE.CHANGE 

BOOLEAN  :=  FALSE; 

end  record  ; 

type  DESIGNER_RECORD  is  record 

NEXT 

DELINK; 

D_naitie 

:  String ( 1 . .16) ; 

LEVEL  :  EXPERTISE. 

.LEVEL ; 

end  record  ; 

type  SCHEDULE_RECORD  is 

record 

NEXT 

:  LlNKl; 

STEP_ID 

:  natural; 

START.TIME 

:  natural; 

FINISH^TIME 

:  natural; 

DESIGNER^NO 

:  natural; 

STEP_LEVEL 

:  EXPERTISE^LEVEL; 

DESIGNEP.^LEVEL 

:  EXPERTISE_LEVEL; 

end  record  ; 

type  VECTOR  is  array 

(POSITIVE  range  <>)  of  integer; 

type  designer_matrix 

is  array  (POSITIVE  range 

<>. 

POSITIVE  range  <>)of  natural; 

type  LIST_VECTOR  is 

array  (POSITIVE  range  <>) 

of 

link; 

type  SCHEDULE^VECTOR 

is  array  (POSITIVE  range 

<>) 

of  linkl; 

DEADLINEl 

:  nat_map.inap; 

PRIORITYl 

:  nat_inap .  map ; 

ESTIMATED_DURATI ONI 

:  nat_inap  .mep; 

EARL I EST_START_TIME1 

:  nat_map.map; 

EXP_LEVEL1 

:  exp_inap .map; 

SUCCESSORS! 

set_map . map ; 

PREDECESSORS! 

;  set_map.map; 
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--  Creating  new  step, 
procea.ire  CREATE_NEW_STEP; 

--  Linking  a  step  to  the  tail  of  the  step  list 
procedure  INSERT_NEW_STEP  (LIST  ,TAIL, 

A_RECORD  :  in  out  LINK  ) ; 

--  Creating  new  step  from  a  file  and  linking  it  to 
--  step  list. 

procedure  CREATE_AND_INSERT_NEW_STEP  (LIST  ,  TAIL  : 

in  out  LINK  )  ; 

procedure  CREATE_DESIGNER_LIST(D_LIST  :  in  out  D_LINK; 

NO_LOW  :  in  out  natural; 
NO_MED  :  in  out  natural; 
NO_HIG  :  in  out  natural); 

procedure  INSERT_D_record (HEAD, A_RECORD: in  out  D_LINK 


procedure  FIND_DESIGNER(HEAD  :  in  DELINK; 

D_INDEX  ;  in  natural; 
d_name  :  out  string) ; 


procedure  se:_successors (LIST  :  in  out  LINK); 

—  resetting  the  in_degree  of  the  steps  in  the  step 

—  list  for  rescheduling 

procedure  RESET_IN_DEGREE(LIST  :  in  out  LINK) ; 

--  creating  a  new  schedule  record 
procedure  CREATE_SCHEDULE_RECORD ( 

S_ID  :  in  natural; 

TIMEl  :  in  natural; 

TIME  :  in  natural; 

D_NO  :  in  natural; 

S_LEVEL  :  in  EXPERTISE_LEVEL; 
D^LEVEL  :  in  EXPERTISE_LEVEL) ; 


/ 


--  DISPLAY  THE  MAIN  MENU, 
procedure  SCHEDULER_MENU; 


--  PRINTING  A  SCHEDULE  HEADING  LINE  BEFORE  PRINTING 
--  ANY  RECORD. 
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procedure  SCHEDULE_RECORD_HEADING ; 

--  display  a  record  given  its  position  in  the  list, 
procedure  DISPLAY_SCHEDULE_RECORD ( 

CURRENT: in  LINKl ; 
my^list  :  D_LINK  ; 
d_vector:  in  vector  ) ; 

--  print  all  the  records  in  the  SCHEDULE  list, 
procedure  PRINT_ALL_SCHEDULE_RECORDS ( 

HEAD  :  in  LINKl; 
iny_list:D_LINK  ; 
d_vector :  in  vector  )  ; 

--  PRINTING  A  STEP  HEADING  LINE  BEFORE  PRINTING  ANY 
--  RECORD. 

procedure  STEP_RECORD_HEADING; 

--  display  a  record  given  its  position  in  the  list, 
procedure  DISPLAY_STEP_RECORD  (CURRENT  :  in  LINK  )  ; 

—  print  all  the  records  in  the  STEP  list, 
procedure  PRINT_ALL_STEP_RECORDS (HEAD  :  in  LINK  ); 

--  print  all  the  records  in  the  READY  QUEUE, 
procedure  PRINT_ALL_QUEUE_RECORDS (HEAD  in  LINK  ); 


--  Linking  a  step  to  the  ready  list  in  order  of  its 
--  deadline. 

procedure  INSERT_ORDER_DEADLINE ( 

REQUEUE  ;in  out  LINK; 

A_RECORD  :  in  LINK  ) ; 

--  Linking  a  step  to  the  ready  list  in  order  of  its 
—  start  time. 

procedure  INSERT_ORDER_START_TIME ( REQUEUE  . 

A_RECORD  :  in  out  LINK  ) ; 

--  Linking  a  step  to  the  pending  list  in  order  of 
--  its  start  time. 

procedure  INSERT_PENDING_ORDER_START_TIME ( R_QUEUE , 

A_RECORD  :  in  out  LINK  ) ; 

--  Linking  a  step  to  the  ready  list  in  order  of  its 

--  (DEADLINE  Start  time)  . 

procedure  INSERT_ORDER_MIXED (R_QUEUE  , 
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A_RECORD  :  in  out  LINK  ) ; 

--  Linking  a  step  to  the  ready  list  in  order  of  its 
--  laxity. 

procedure  INSERT_ORDER_LAXITY (R_QUEUE  , 

A_RECORD  :  in  out  LINK  ) ; 
--  Linking  a  schedule  record  to  the  tail  of  the 
--  schedule  list 

procedure  INSERT_NEW_SCHEDULE_RECORD{LIST  ,TAIL, 

A_RECORD  :  in  out  LINKl ) ; 

--  Linking  a  schedule  record  according  to  its 
--  expertise  level 

procedure  INSERT_ORDER_EXP_LEVEL { HEAD .  A_RECORD : 

in  out  LINKl  ) ; 

--  Linking  a  schedule_record  to  the  schedule  in 
--  order  of 

—  its  start  time. 

procedure  INSERT_ORDER_START_TIME  (HEAD,  A_RECORD  : 

in  out  LINKl  ) ; 

--  Linking  a  schedule_record  to  the  schedule  in 
--  order  of  its  step  id. 

procedure  INSERT_ORDER_STEP_ID  (HEAD,  A_RECORD  :  in 

out  LINKl  ) ; 

_«***♦*♦*•*»**********♦**********************★************** 

procedure  LEVEL_MINMUM (MATRIX  :  in  DESIGNER_MATRIX; 

LEVEL  :  in  EXPERTISE_LEVEL; 
MAX^LEVEL  ;  in  natural; 
ROW_LENGTH  :  in  vector  ; 

L,  J  :  in  out  natural); 

function  ROW_MINMUM (MATRIX  :  in  DESIGNER_MATRIX; 

LEVEL  :  in  EXPERT1SE_LEVEL; 

ROW_LENGTH  :  in  vector) return 

natural  ; 

--  Search  for  target  step.  Return  the  position  and 
--  previous  if  found 

—  •  Record  not  found  "  if  not  found, 
procedure  FIND_STEP  (HEAD  :  in  LINK; 

S_ID  :  in  natural ; 

POSITION  :  in  out  LINK; 
PREVIOUS  :  in  out  LINK; 
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FOUND 


:  in  out  boolean) ; 


--  Delete  a  step  from  step  list. 

procedure  DELETE_FROM_STEP_LIST  (HEAD:  in  out  LINK; 

POSITION  :  in  LINK; 
PREVIOUS  :  in  LINK) ; 

--  Delete  a  step  from  pending  list 
procedure  DELETE_FROM_PENDING_LIST  (HEAD  :  in  out  LINK; 

POSITION  :  in  LINK; 
PREVIOUS  :  in  LINK) ; 

—  Delete  a  step  from  schedule, 
procedure  DELETE_FROM_SCHEDULE  (HEAD  :  in  out  LINKl; 

POSITION  :  in  LINKl; 
PREVIOUS  :  in  LINKl ) ; 

--  Delete  a  step  found  by  search  and  relinlc  step 

—  list. 

procedure  DELETE_FROM_READY_QUEUE  (  HEAD:  in  out 

LINK) ; 

Decrementing  the  in_degree  of  the  successors  of  a  step 
procedure  DECREMENT_IN_DEGREE  (STEP,  LIST:  in  out  LINK; 

finish_t  :  in  natural) ; 

function  list_size(LIST  :in  LINK)  return  natural; 

--  checking  the  in_degree  of  the  successors  of  the 

—  assigned  step 

—  This  works  with  deadline  heuristic  (mixed  and 

—  laxity  too) 
procedure  CHECK_IN_DEGREE  ( 

STEP,  R_QUEUE  ,  LIST  :  in  out  LINK; 
finish_t  :  in  natural) ; 

--  checking  the  in_degree  of  the  successors  of  the 
--  assigned  step 

--  This  works  with  start  time  heuristic, 
procedure  CHECK_IN_DEGREE_1  (STEP,  LIST  :  in  out  LINK; 

REQUEUE  :  in  out  LIST_VECTOR; 

finish_t  :  in  natural); 

procedure  CHECK_IN_DEGREE_2  (STEP,  LIST  :  in  out  LINK; 

REQUEUE  :  in  out  LIST_VECTOR; 


f inish_t 


:  in  natural); 


--  checking  the  pending  list  for  ready  steps  of  a 
--  certainlevel  and  insert  them  into  the 
--  corresponding  ready_list  according  to  their 
--  deadlines 

procedure  GET_READY_STEPS  ( t ,  )c  ;  in  natural  ; 

LIST  :  in  out  LINK; 

R_QUEUE  :  in  out  LIST_VECTOR) ; 
--  checking  the  pending  list  for  ready  steps  of  a 
--  certain  level  and  insert  them  into  the 
—  corresponding  ready_list 

--  according  to  their  (deadlines  +  start  times) . 
procedure  GET_READY_STEPS_1  { t ,  k  :  in  natural  ; 

LIST,  R_QUEUE  :  in  out  LINK) ; 

--  checking  the  pending  list  for  ready  steps  of  a 
--  certain  level  and  insert  them  into  the 
--  corresponding  ready_list  according  to  their 
--  LAXITY. 

procedure  GET_READY_STEPS^2 { t ,  k  :  in  natural  ; 

LIST,  REQUEUE  :  in  out  LINK)  ; 

--  get  the  top  steps  in  the  ready  list  and 
--  insert  them  into  the  corresponding  ready _list 
--  according  to  their  deadlines 

procedure  GET_READY_STEPS  (LIST  :in  out  LINK; 

REQUEUE  :  in  out  LIST_VECTOR) ; 

--  get  the  top  steps  in  the  ready  list  and 
--  insert  them  into  the  corresponding  ready_list 
--  according  to  their  (deadlines  +  start  times) . 
procedure  GET_READY_STEPS_1  (LIST  :in  out  LINK; 

REQUEUE  ;  in  out  LIST.VECTOR) ; 

—  get  the  top  steps  in  the  ready  list  and 
--  insert  them  into  the  corresponding  ready_list 
--  according  to  their  Laxity, 

procedure  GET_READY_STEPS_2  (LIST  :in  out  LINK; 

REQUEUE  :  in  out  LIST_VECTOR) ; 


procedure  SUGGEST_DEADLINE_SLIP(step  :  in  out  link; 

value  : in  natural); 

--  checking  the  feasibility  of  the  schedule  with 
--  each  step  in  the  ready  queue 
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procedure  STRONGLY_FEASIBLE (R_QUEUE  :  in  LINK; 

MATRIX  :  in  DESIGNER_MATRIX ; 

D_VECTOR  :  in  vector; 

MAX_LEVEL  :  in  natural; 

FEASIBLE  :  in  out  boolean  ) ; 


-  Assign  a  step  to  a  designer  according  to  its  deadline 
and  its  expertise  level 

procedure  ASSIGN_STEP(R_QUEUE  :  in  out  LIST_VECTOR; 

LIST  :  in  out  LINK; 

MATRIX  :  in  out  DESIGNER_MATRIX; 
ROW^LENGTH  :  in  vector; 

M,N  :  in  out  natural; 

L  :  in  natural; 

SCH  :  in  out  LINKl; 

done  :  out  boolean  ) ; 


—  reset  the  step  list  and  the  schedule  for 

—  incrementing  the  schedule 

--  with  new  steps  at  certain  time 
procedure  RESET_FOR_RESCHEDULING ( 
d..list  :in  out  D_LINK; 

LIST  :  in  out  LINK; 

MATRIX  :  in  out  DESIGNER.MATRIX; 

d_vector  :  in  vector) ; 

procedure  FIND_DESIGNER_POSITION (HEAD  :  in  D_LINK; 

D_INDEX  ;  out  natural; 
d_neune  :  in  string)  ; 


end  scheduler; 
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package  body  scheduler  is 


package  nat_io  is  new  integer_io( natural)  ;  use  nat_io; 
procedure  put_set  is  new  generic_put ; 
procedure  get_set  is  new  generic_input ; 
procedure  getf_set  is  new  generic_f ile_input ; 
procedure  FREE  is  new 

UNCHECKED_DEALL0CAT10N(STEP_REC0RD,  LINK) ; 
procedure  FREEl  is  new 

UNCHECKED_DEALL0CAT10N ( SCHEDULE_RECORD .  LINKl ) ; 
package  enu_io  is  new 

text_io . ENUMERATION_IO ( EXPERTISE.LEVEL ) ; 

STEP_ID  ;  natural  :=1; 

NEW_RECORD  :  LINK;--  new  step  record 

NEW_S_RECORD  :  LINKl;--  new  schedule  record 
MY_RECORD  :  DELINK;--  new  designer  record 

—  logical  file  definitions 
data_file,data.filel  :  FILE^TYPE; 
input  :  stringd .  .  10)  ; 

--  physical  file  name  that  include  step  data 
E_level_error  : except ion; 

***•**•«***'**•***«•******«**'***#**•****««*********«**•*•* 

—  Creating  new  step  for  standard  input, 
procedure  CREATE_NEW_STEP  is 
begin 

NEW.RECORD  :=  new  STEP_RECORD  ; 

--  assign  values  to  record  fields. 

NEW_RECORD . STEP^ID  :=  STEP_ID; 
put^line { “Please  Enter  DEADLINE  "); 
get (NEW_RECORD. DEADLINE  ); 
put_line ( “Please  Enter  PRIORITY  “); 
get ( NEW_RECORD . PRIORITY  ) ; 

puc_line{ “Please  Enter  ESTIMATED_DURAT10N  “); 
get ( NEW_RECORD . ESTIMATED_DURATION  ) ; 
put_line{ “Please  Enter  EARLIEST  START  TIME  " )  ; 
get {NEW_RECORD.EARLIEST_START_TIME) ; 
put_line( "Please  Enter  PREDECESSORS  “); 
get_set (NEW_RECORD. PREDECESSORS) ; 
put_line( “Please  Enter  SUCCESSORS  “ ) ; 
get_set (NEW_RECORD. SUCCESSORS) ; 
put_line( “Please  Enter  EXPERTISE  LEVEL  REQUIRED 

enu_io.get (NEW_RECORD.EXP_LEVEL) ; 
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PREDECESSORS  :=  NEW_RECORD. PREDECESSOR S; 
NEW_RECORD . IN_DEGREE  := 
s i ze ( NEW_RECORD . PREDECESSORS ) ; 

skip_line; 

end  CREATE_NEW_STEP; 


--  Linking  a  step  to  the  tail  of  the  step  list 
procedure  INSERT_NEW_STEP  (LIST  ,  TAIL, 

A_RECORD  :  in  out  LINK  )  is 

begin 

if  LIST  =  null 
then  A_RECORD,NEXT  :=  LIST; 

LIST  :=  A_RECORD  ; 
else 

TAIL. NEXT  :=  A.RECORD  ; 
end  if; 

TAIL  :=  A_RECORD  ; 
end  INSERT_NEW_STEP; 


--  Creating  new  step  from  a  file. 

procedure  CREATE_AND_INSERT_NEW_STEP(LIST,  TAIL: 

in  out  LINK  )  is 

begin 

OPEN(data_file,  IN_FILE,  -temps’); 

WHILE  not  END_OF_FILE(data_file)  loop 
NEW_RECORD  new  STEP_RECORD  ; 

--  assign  values  to  record  fields, 
get {data_f ile, NEW_RECORD. STEP_ID  ) ; 
get (data_file,NEW_RECORD. DEADLINE  ) ; 
get (data_file,  NEW_RECORD. PRIORITY  ); 
get {data_file,  NEW_RECORD . ESTIMATED_DURATION  )  ; 
getf^set (data_file,  NEW_RECORD . PREDECESSORS ) ; 
enu_io .get (data_f ile,  NEW_RECORD . EXP.LEVEL) ; 
get (data_f ile, NEW_RECORD . IN_DEGREE) ; 
INSERT_NEW_STEP(LIST,  TAIL, NEW_RECORD) ; 
end  ] oop ; 

CLOSE  (data_file); 
set_successors (LIST) ; 
exception 

when  DATA_ERROR  => 

put_line( "Step  is  not  in  approved  state”); 
when  constraint_error  => 

put_line ( -Step  is  not  in  approved  state"); 
when  others  => 


323 


null  ; 

end  CREATE_AND_INSERT_NEW_STEP; 


procedure  CREATE_DESIGNER_LIST(D_LIST  :  in  out 

DELINK; 

NO_LOW  :  in  out  natural; 
NO_MED  :  in  out  natural; 
NO_HIG  :  in  out  natural) is 

Length  :  integer; 
begin 

NO_LOW  :a  0; 

NO_MED  :=  0; 

NO_HIG  :a  0; 

OPEN(data_filel.  IN_FILE,  “temp2"); 

WHILE  not  END_OF_FILE (data_f ilel )  loop 
MY_RECORD  :=  new  DESIGNER.RECORD  ; 

--  assign  values  to  record  fields, 
get ( data^f ilel , MY_RECORD . D_name ) ; 
for  i  in  Length+1..20  loop 

MY_RECORD . D_name { i ) : » •  •  ; 
end  loop; 

put (MY_RECORD.D_name) ; 
enu_io. get {data_f ilel, MY.RECORD. LEVEL  ) ; 
skip_line(data_filel) ; 

enu^io.put (MY_RECORD. LEVEL) ; 
new.line; 

if  MY_RECORD. LEVEL  »  low  then  NO_LOW : =NO_LOW  +1; 
elsif  MY_RECORD . LEVEL  =  medium  then  NO_MED  :  = 
NO_MED  +1; 

else  NO_HIG  :=  NO_HIG  +  1; 
end  if; 

insert_D_record ( D_LIST, MY_RECORD ) ; 
end  loop; 

CLOSE  (data_filel) ; 
end  CREATE_DESIGNER_LIST; 

--  Linking  a  deigner  record  according  to  its 
--  expertise  level 

procedure  INSERT_D_record  (HEAD  ,  A_RECORD  :  in  out 

D_LINK  )  is 

CURRENT  :  D_LINK  :=  HEAD  ; 

PREVIOUS  :  D_LINK  :=  null; 

LARGER_FOUND  :  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  /*  null  and  not  LARGER_FOUND  loop 


324 


if  CURRENT. u£VEL  >  A_RECORD . LEVEL  then 
LARGER_FOUND  :=  TRUE  ; 
else 

PREVIOUS  :=  CURRENT  ; 

CURRENT  :=  CURRENT. NEXT  ; 
end  i f  ; 
end  loop; 

A_RECORD.NEXT  :=  CURRENT  ; 
if  PREVIOUS  =  null  then 
HEAD  :=  A_RECORD  ; 

else 

PREVIOUS. NEXT  :=  A_RECORD  ; 
end  i f  ; 

end  INSERT_D_record; 


--  Search  for  target  step.  Return  the  position  and 
--  previous  if  found, 

--  ‘  Record  not  found  •  if  not  found, 
procedure  FIND_DESIGNER(HEAD  :  in  D_LINK; 

D^INDEX  :  in  natural; 
d^name  :  out  string)  is 
POSITION  :  D_LINK  :=  HEAD  ; 

K  :  natural  :=1; 
begin 

while  POSITION  /=  null  and  K  /=  D.INDEX  loop 
POSITION  :=  POSITION. NEXT  ; 
k  ;=  k+1; 
end  loop  ; 

d_naine  :=  POSITION. D_naine; 
end  FIND_DESIGNER  ; 


procedure  set_successors (LIST  :  in  out  LINK)  is 
CURRENT  :  LINK  r=  LIST; 
current 1 :  LINK ; 
begin 

while  CURRENT  /=  null  loop 

if  size (CURRENT. PREDECESSORS)  /=  0 

then 

current 1 ; =LIST; 
while  current 1  /=  null  loop 
if  member (current 1 . St ep_id, 
CURRENT. PREDECESSORS ) 
then  add (CURRENT. STEP_ID, 
currentl . successors ) ; 
end  if; 
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/ 


current 1  :=  current  1 .next ; 
end  loop; 
end  if; 

CURRENT  :=  CURRENT. NEXT; 
end  loop; 

end  set_successors; 


--  resetting  the  in_degree  of  the  steps  in  the  step  list 
--  for  rescheduling 

procedure  RESET_IN_DEGREE(LIST  :  in  out  LINK)  is 
CURRENT  :  LINK  :=  LIST; 
begin 

while  CURRENT  /=  null  loop 
CURRENT. 1N_DEGREE  := 

size (CURRENT. PREDECESSORS) ; 
CURRENT  :=  CURRENT . NEXT ; 
end  loop; 

end  RESET_1N_DEGREE; 


->  creating  a  new  schedule  record 
procedure  CREATE_SCHEDULE_RECORD  ( 

S_ID  ;  in  natural; 

TIMEl  :  in  natural; 

TIME2  :  in  natural; 

D_NO  :  in  natural; 

S.LEVEL:  in  EXPERTISE_LEVEL; 
D_LEVEL:in  EXPERTISE_LEVEL)  is 

begin 

NEW_S_RECORD  :=  new  SCHEDULE_RECORD  ; 
NEW_S_RECORD . STEP_ID  ;=  S_ID; 
NEW_S_RECORD.START_TIME  :=  TIMEl; 
NEW_S_RECORD.FINISH_TIME  :=  TIME2 ; 
NEW_S_RECORD.DESIGNER_NO  :=  D_NO; 
NEW_S_RECORD . STEP_LEVEL  : =S_LEVEL ; 
NEW_S_RECORD.DESIGNER_LEVEL  :=  D_LEVEL; 
end  CREATE_SCHEDULE_RECORD ; 

—  ******************************************************  *  *  *  « 

--  PRINTING  A  SCHEDULE  HEADING  LINE  BEFORE  PRINTING 
--  ANY  RECORD. 

procedure  SCHEDULE_RECORD_HEADING  is 
begin 

put{"STEP_ID  S_LEVEL  D_NAME 
START_TIME  FINISH_TIME" ) ; 

new_line; 


326 


putC* . .  . 

. ■)  ; 

new_l ine ; 

end  SCHEDULE_RECORD_HEADING  ; 

--  display  a  record  given  its  position  in  the  list, 
procedure  DISPLAY_SCHEDULE_RECORD ( 

CURRENT  :  in  LINKl ; 
my.list  :  D_LINK; 
d_vector:  in  vector  )  is 

iiy_index  :  natural; 
my_name  :  string (1 .. 16) ; 
begin 

SET_C0L{4) ; 

test_io_p)cg.put  (CURRENT. STEP_ID)  ; 

SET.COLdl)  ; 

enu_io . put ( CURRENT . STEP_LEVEL ) ; 
SET_C0L(21) ; 

if  CURRENT. DESIGNER_LE'/EL  =  high  then 
rny_index  CURRENT. DESIGNER_NO  ♦ 

d^vector ( 1 ) ♦d_vector ( 2 )  ; 
elsif  CURRENT. DESIGNER_LEVEL  =  medium  then 
nty_index  ;=  CURRENT. DESIGNER.NO  +  d_vector(l)  ; 
else 

my^index  :*  CURRENT. DESIGNER.NO  ; 
end  if; 

FIND_DESIGNER(itiy_list,  my_index,  iiiy_name)  ; 
put  (iny_ncune)  ; 

SET_COL ( 37 ) ; 

test_io_pkg . put { CURRENT . START_TIME ) ; 
SET_COL(48) ; 

test_iojpkg.put (CURRENT. FINISH_TIME) ; 
new^line; 

end  DI S PLAY.SCHEDULE^RECORD ; 

--  print  all  the  records  in  the  SCHEDULE  list, 
procedure  PRINT_ALL_SCHEDULE_RECORDS  ( 

HEAD  :  in  LINKl; 
nty_list  :  D_LINK; 
d_vector:  in  vector  )  is 
CURRENT  :  LINKl  :=  HEAD  ; 
begin 

while  CURRENT  /=  null  loop 

DISPLAY_SCHEDULB_RECORD  (CURRENT, my_list , 
d_vector)  ; 

CURRENT  :=  CURRENT. NEXT  ; 


327 


end  loop; 

end  PRINT_ALL_SCHEDULE_RECORDS  ; 


--  PRINTING  A  STEP  HEADING  LINE  BEFORE  PRINTING  AH'/ 
--  RECORD. 

procedure  STEP_RECORD_HEADING  is 
begin 

put{“STEP_ID  DEADLINE  PRIORITY  PREDECE  SUCCESS 
LEVEL  IN_DEGRSE" ) ; 
new_line; 

put  (• -  -  -  -  - 

new_line; 

end  STEP_RECORD_HEADING  ; 


--  display  a  record  given  its  position  in  the  list, 
procedure  DISPLAy_STEP_RECORD (CURRENT  :  in  LINK  )  is 
tempi  :  natural; 
begin 

SET_COL(4) ; 

test_io_pkg.put  (CURRENT.  STEP..ID)  ; 

SET.COL ( 12 ) ; 

test_io_pkg.put (CURRENT. DEADLINE) ; 
SET_COL(23) ; 

test_io_pkg.put (CURRENT. PRIORITY) ; 
SET_COL(3l) ; 

put_set (CURRENT. PREDECESSORS) ; 
SET_COL(41) ; 

put_set (CURRENT. SUCCESSORS) ; 

SET_COL(49) ; 

enu_i o .  put  ( CURRENT .  c.aP_LEVEL  )  ; 
SET_C0L(61) ; 

test_io_pkg.put (CURRENT. IN.DEGREE) ; 
new_line; 

end  DISPLAY_STEP_REC0RD; 

--  print  all  the  records  in  the  STEP  list, 
procedure  PRINT_ALL_STEP_RECORDS (HEAD  :  in  LINK  )  is 
CURRENT  :  LINK  :=  HEAD  ; 
begin 

while  CURRENT  /*  null  loop 

DISPLAY_STEP_RECORD  (CURRENT)  ; 

CURRENT  :=  CURRENT. NEXT  ; 
end  loop; 

end  PRINT_ALL_STEP_RECORDS  ; 
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--  print  all  the  records  in  the  READY  QUEUE, 
procedure  PR1NT_ALL_QUEUE_REC0RDS (HEAD: in  LINK  )  is 
CURRENT  :  LINK  :=  HEAD  ; 
begin 

while  CURRENT  /=  null  loop 

DISPLAY^STEP^RECORD  (CURRENT)  ; 

CURRENT  :=  CURRENT . NEXT_READY  ; 
end  loop; 

end  PRINT_ALL_QUEUE_RECORDS  ; 


--  DISPLAY  THE  MAIN  MENU, 
procedure  SCHEDULER_MENU  is 
begin 

new_line; 

set_col(25);  put (“MAIN  MENU“);  new_line; 

set_col(25);  put(* - ");  new_line(2); 

set_col  (10)  ;  putCdl  schedule  steps  according 
to  their  deadlines'); 

new_line; 

set_col (10) ;  put (“[2]  schedule  steps  according 
to  their  start  time*); 

new^line; 

set_col(10);  put  (“(3]  schedule  steps  according 
to  (deadline  +  start  time)*); 
new_line; 

set_col(10);  put(*[4)  schedule  steps  according 
to  their  laxity  "); 

new_line; 

set_col(10);  put (“[5]  Print  schedule"); 
new_line; 

set_col(10);  put ("[6]  Print  ready  queue"); 
new_line; 

set_col(10);  put(*(7J  Print  a  particular  step"); 
new_line; 

set_col(10);  put (*[8]  Print  step  list"); 
new^line; 

set_col{10);  put(*[9]  Quit");  new_line(3); 
set^coKlO);  put("Enter  the  number  of  your  choice 

:  ")  ; 


end  SCHEDULER_MENU  ; 


--  Linlcing  a  step  to  the  ready  list  in  order  of  its 
--  deadline. 

procedure  INSERT_ORDER_DEADLINE ( 
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REQUEUE  :  in  out  LINK; 

A_RECORD  :  in  LINK  )  is 
CURRENT  :  LINK  :=  R_QUEUE  ; 

PREVIOUS  ;  LINK  :=  null  ; 

LARGER_FOUND  ;  BOOLEAN  :=  PALS"!  ; 
begin 

while  CURRENT  /*  null  and  not  LARGER_FOUND  loop 
if  CURRENT. DEADLINE  >  A_RECORD , DEADLINE  then 
LARGER_FOUND  :=*  TRUE  ; 
else 

PREVIOUS  :=  CURRENT  ; 

CURRENT  :=  CURRENT . NEXT_READY  ; 
end  i f  ; 
end  loop; 

A_RECORD.NEXT_READY  :=  CURRENT  ; 
if  PREVIOUS  =  null  then 
R_QUEUE  :=  A_RECORD  ; 
else 

PREVIOUS. NEXT_READY  :=  A_RECORD  ; 
end  if  ; 

end  INSERT_ORDER_DEADLINE; 


—  Linking  a  step  to  the  ready  list  in  order  of  its 
--  start  time. 

procedure  INSERT_ORDER_START_TIME ( REQUEUE , 

A_RECORD  :  in  out  LINK  )  is 
CURRENT  :  LINK  R_QUEUE  ; 

PREVIOUS  ;  LINK  :*  null  ; 

LARGER_FOUND  ;  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  /=  null  and  not  LARGER_FOUND  loop 
if  CURRENT. EARLIEST_START_TIME  > 

A.RECORD . EARLIEST_START_TIME 

then 

LARGER.FOUND  :»  TRUE  ; 

else 

PREVIOUS  :=  CURRENT  ; 

CURRENT  :=  CURRENT . NEXT_READY  ; 
end  if  ; 
end  loop; 

A^RECORD . NEXT_READY  :=  CURRENT  ; 
if  PREVIOUS  =  null  then 
R_QUEUE  ;=  A^RECORD  ; 
else 
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PREVIOUS. NEXT.READY  :=  A_RECORD  ; 
end  i f  ; 

end  1NSERT_0RDER_START_TIME; 


--  Linking  a  step  to  the  ready  list  in  order  of  its 
—  start  time. 

procedure  INSERT_PENDING_ORDER_START_TIME ( R_QUEUE , 

A_RECORD  ;  in  out  LINK  )  is 
CURRENT  :  LINK  :*  REQUEUE  ; 

PREVIOUS  ;  LINK  :=  null  ; 

LARGER_FOUND  :  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  /=  null  and  not  LARGER_FOUND  loop 
if  CURRENT. EARLIEST_START_TIME  > 

A_RECORD . EARLI EST_START_TIME  t  hen 
LARGER^FOUND  :a  TRUE  ; 
else 

PREVIOUS  CURRENT  ; 

CURRENT  :=  CURRENT . NEXT_PENDING  ; 
end  if  ; 
end  loop; 

A_REC0RD.NEXT_PEND1NG  :=  CURRENT  ; 
if  PREVIOUS  =  null  then 
R_QUEUE  :=  A.RECORD  ; 
else 

PREVIOUS. NEXT_PENDING  :=  A_RECORD  ; 
end  i f  ; 

end  INSERT_PENDING_ORDER_START_TIME ; 


--  Linking  a  step  to  the  ready  list  in  order  of  its 
--  (DEADLINE  start  time)  . 

procedure  INSERT_ORDER_MIXED( REQUEUE,  A_RECORD  :  in 

out  LINK  )  is 

CURRENT  :  LINK  :»  R_QUEUE  ; 

PREVIOUS  :  LINK  ;=  null  ; 

LARGER_FOUND  :  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  /=  null  and  not  LARGER_FOUND  loop 
i f  ( CURRENT . EARLI EST_START_TIME  + 

CURRENT . DEAD! INE ) > 

{ A_RECORD . EARLIEST.START^TIME  + 

A_RECORD . DEADLINE ) 
then  LARGER_F?^-']ND  :=  TRUE  ; 
else 
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PREVIOUS  :=  CURRENT  ; 

CURRENT  CURRENT . NEXT_READY  ; 

end  i £  ; 
end  loop; 

A_RECORD.NEXT_READy  CURRENT  ; 
if  PREVIOUS  =  null  then 
R_QUEUE  :=  A_RECORD  ; 
else 

PREVIOUS. NEXT_READY  :=  A_RECORD  ; 
end  if  ; 

end  INSERT_ORDER_MIXED; 


—  Linking  a  step  to  the  ready  list  in  order  of  its 
--  laxity  (deadline  -  (est  +  duration) ) . 
procedure  INSERT_ORDER_LAXITY (REQUEUE,  A_RECORD  : 

in  out  LINK  )  is 

CURRENT  :  LINK  :=  R_QUEUE  ; 

PREVIOUS  :  LINK  :=  null  ; 

LARGER_FOUND  :  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  /=  null  and  not  LARGER_FOUND  loop 
if  (CURRENT. DEADLINE  - 

(CURRENT. EARLIEST_START_TIME  CURRENT. ESTIMATED_DURATION)  ) 

>  (A.RECORD. DEADLINE  - (A_RECORD.EARLIEST_START_TIME  + 
A_RECORD.ESTIMATED_DURATION) ) 

then  LARGER_FOUND  :=  TRUE  ; 
else 

PREVIOUS  :=  CURRENT  ; 

CURRENT  :=  CURRENT . NEXT_READY  ; 
end  i f  ; 
end  loop; 

A_RECORD.NEXT_READy  :=  CURRENT  ; 
if  PREVIOUS  =  null  then 
REQUEUE  A_RECORD  ; 
else 

PREVIOUS. NEXT_READy  ;=  A_RECORD  ; 
end  if  ; 

end  INSERT_ORDER_LAXITY; 


--  Linking  a  schedule  record  to  the  tail  of  the 
--  schedule  list 


procedure  INSERT_NEW_SCHEDULE_RECORD (LIST  . TAIL , 

A_RECORD  :  in  out  LINKl)  is 


begin 
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if  LIST  =  null 
then  A_RECORD.NEXT  :=  LIST; 

LIST  :=  A_RECORD  ; 
else 

TAIL. NEXT  :=  A_RECORD  ; 
end  if; 

TAIL  A_RECORD  ; 
end  INSERT_NEW_SCHEDULE_RECORD; 


--  Linking  a  schedule  record  according  to  its 
--  expertise  level 

procedure  INSERT_ORDER_EXP_LEVEL  (HEAD  ,  A_RECORD  : 

in  out  LINKl  )  is 

CURRENT  :  LINKl  :=  HEAD  ; 

PREVIOUS  :  LINKl  :=  null; 

LARGER_FOUND  :  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  !-  null  and  not  LARGER_FOUND  loop 
if  CURRENT. DESIGNER_LEVEL  > 

A_RECORD.DESIGNER_LEVEL  then 
LARGER.FOUND  :=  TRUE  ; 
else 

PREVIOUS  :*  CURRENT  ; 

CURRENT  ;=  CURRENT. NEXT  ; 
end  i f  ; 
end  loop; 

A.RECORD.NEXT  :=  CURRENT  ; 

PREVIOUS  =  null  then 
HEAD  :*  A_RECORD  ; 

else 

PREVIOUS. NEXT  :»  A_RECORD  ; 
end  if  ; 

end  INSERT_ORDER_EXP_LEVEL; 


—  Linking  a  schedule_record  to  the  schedule  in 
--  order  of  its  start  time. 

procedure  INSERT_ORDER_START_TIME  (HEAD  ,  A_RECORD 

:  in  out  LINKl  )  is 

CURRENT  :  LINKl  :=  HEAD  ; 

PREVIOUS  :  LINKl  :=  null; 

LARGER_FOUND  :  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  /x  null  and  not  LARGER_FOUND  loop 
if  CURRENT . START_TIME  >=  A_RECORD . START_TIME  then 
LARGER_FOUND  :=  TRUE  ; 
else 
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PREVIOUS  :=  CURRENT  ; 
CURRENT  :=  CURRENT. NEXT  ; 
end  1 £  ; 
end  loop; 

A_RECORD . NEXT  :=  CURRENT  ; 
if  PREVIOUS  =  null  then 
HEAD  ;=  A_RECORD  ; 
else 

PREVIOUS. NEXT  :=  A_RECORD  ; 
end  if  ; 

end  INSERT_ORDER_START_TIME; 


--  Linking  a  schedule_record  to  the  schedule  in 
--  order  of  its  step  id. 

procedure  INSERT_ORDER_STEP_ID  (HEAD  .  A_RECORD 

;  in  out  LINKl  )  is 

CURRENT  :  LINKl  :=  HEAD  ; 

PREVIOUS  :  LINKl  null; 

LARGER_FOUND  :  BOOLEAN  :=  FALSE  ; 
begin 

while  CURRENT  /=  null  and  not  LARGER_FOUND  loop 
if  CURRENT . STEP_ID  >=  A_RECORD . STEP_ID  then 
LARGER_FOUND  :=  TRUE  ; 

else 

PREVIOUS  :*  CURRENT  ; 

CURRENT  :=  CURRENT. NEXT  ; 
end  if  ; 
end  loop; 

A_RECORD.NEXT  :=  CURRENT  ; 
if  PREVIOUS  =  null  then 
HEAD  :=  A_RECORD  ; 
else 

PREVIOUS. NEXT  :=  A_RECORD  ; 
end  if  ; 

end  INSERT_ORDER_STEP_ID; 


procedure  LEVEL_MINMUM  (MATRIX  :  in  DESIGNER_MATRIX; 

LEVEL  :  in  EXPERTISE_LEVEL; 

MAX_LEVEL  :  in  natural; 
ROW_LENGTH  :  in  vector  ; 

L,  J  :  in  out  natural)  is 

MIN  :  natural; 

temp  :  natural  :=  EXPERTISE_LEVEL ' POS (LEVEL)  +  1; 
begin 

L  temp; 
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J  ;=  1; 

MIN  :a  1000;  --  MATRIX  (  temp,  1); 

for  k  IN  temp. .MAX_LEVEL  loop 
if  ROW_LENGTH  (k)  /=  0  then 
for  i  IN  1. .ROW_LENGTH  (k)  loop 
if  MIN  >  MATRIX(  k,i)  then 
MIN  :=  MATRIX  {  k.  i)  ; 

L  :=  k; 

J  :=  i; 
end  if; 
end  loop; 
end  if; 
end  loop; 
end  LEVEL_MINMUM; 


function  ROW_MINMUM  (MATRIX  :  in  DESIGNER_MATRIX; 

LEVEL  :  in  EXPERTISE_LEVEL; 

ROW_LENGTH  :  in  vector)  return 

natural  is 

temp  :  natural  :»  EXPERTISE_LEVEL‘ POS (LEVEL)  +  1; 

MIN,  J  :  natural; 

begin 

J:=  1; 

MIN  :*  MATRIX(temp,  J) ; 
for  i  in  1 . .ROW_LENGTH (temp)  loop 
if  MATRIX {  temp.i)  >  MIN  then 
MIN  ;=  MATRIX  (  temp,  i)  ; 

J  ;  =  i ; 

end  if; 
end  loop; 

i f  ROW_LENGTH ( temp ) =  0  then 
return  1000; 
else 

return  J; 
end  if; 

end  ROW_MINMUM; 


--  Search  for  target  step.  Return  the  position  and 
--  previous  if  found, 

--  *  Record  not  found  "  if  not  found, 
procedure  FIND_STEP  (HEAD  :  in  LINK; 

S_ID  :  in  natural; 

POSITION  :  in  out  LINK; 
PREVIOUS  :  in  out  LINK; 

FOUND  :  in  out  boolean)  is 
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begin 

POSITION  :*  HEAD  ; 

PREVIOUS  :=  null  ; 

FOUND  :a  FALSE; 

while  POSITION  /=  null  and  not  FOUND  loop 
if  POSITION. STEP.ID  =  S_ID  then 
FOUND  :s  TRUE  ; 
else 

PREVIOUS  :=  POSITION  ; 

POSITION  :*  POSITION. NEXT  ; 
end  if  ; 
end  loop  ; 

if  FOUND  =  FALSE  then 

put ('STEP  NOT  FOUND  *); 
end  i f  ; 
end  FIND.STEP  ; 


--  Delete  the  step  found  by  search  and  relinks  the  step  list, 
procedure  DELETE_FROM_STEP_LIST  (HEAD  :  in  out  LINK; 

POSITION  :  in  LINK; 
PREVIOUS  :  in  LINK)  is 

begin 

if  HEAD  *  POSITION  then 
HEAD  :=  HEAD. NEXT; 
else 

PREVIOUS. NEXT  :=  POSITION.NEXT; 
end  if; 

end  DELETE_FROM_STEP_LIST; 


--  Delete  the  step  found  by  search  and  relinks  the  step  list, 
procedure  DELETE_FROM_PENDING^LIST  (HEAD  :  in  out  LINK; 

POSITION  :  in  LINK; 
PREVIOUS  :  in  LINK)  is 


begin 

if  HEAD  =  POSITION  then 

HEAD  :=  HEAD.NEXT_PENDING; 
else 

PREVIOUS. NEXT_PENDING  :* 
POSITION . NEXT_PENDING ; 
end  if; 

end  DELETE_FROM_PENDING_LIST; 
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--  Delete  a  step  from  the  schedule, 
procedure  DELETE_FROM_SCHEDULE  {HEAD  :  in  out  LINKl ; 

POSITION  :  in  LINKl; 
PREVIOUS  :  in  LINKl)  is 


begin 

if  HEAD  =  POSITION  then 
HEAD  :=  HE AD. NEXT; 
else 

PREVIOUS. NEXT  :=  POSITION . NEXT; 
end  i £ ; 

end  DELETE_FROM_SCHEDULE; 


--  Delete  a  step  from  the  head  of  the  ready  list, 
procedure  DELETE_FROM_READY_QUEUE ( HEAD : 

in  out  LINK)  is 


begin 

HEAD  HEAD.NEXT.READY; 
end  DELETE_FROM_READY_QUEUE; 

_*•*♦*•**«*♦•*******•******■*•**%**************************** 

--  Decrementing  the  in^degree  of  the  successors  of 
--  a  step  and  adjusting  its  earliest  start  time, 
procedure  DECREMENT_IN_DEGREE  (STEP,  LIST  :in  out  LINK; 

finish_t  :in  natural)  is 

POSITION  :  LINK  :=  LIST; 
t  :  set  :=  STEP . SUCCESSORS ; 
k  :  natural  ; 

kl  :  natural  :=  0; 

FOUND  :  boolean  ;s  FALSE; 
begin 

if  size(t)  /a  0  then 

while  POSITION  /=  null  and  kl  <=  size(t)  loop 
k  :=  POSITION. STEP_ID; 
if  member (k,  t)  then 

if  POSITION. EARLIEST_START_TIME  <  finish_t 
then  POSITION. EARLIEST_START_TIME  :=  finish_t; 
end  if; 

POSITION. IN_DEGREE  :=  POSITION. IN_DEGREE  -  1; 

kl  :=  kl  +  1; 
end  if; 

POSITION  :=  POSITION. NEXT; 


337 


end  loop; 
end  if; 

end  DECREMENT_IN_DEGREE; 


function  list_size(LIST  :  in  LINK) return  natural  is 
current  :  link  :=  LIST; 

K  :  natural  :*  0; 

begin 

while  current  /=  null  loop 
K  :=  K  +  1; 

current  :=  current .NEXT; 
end  loop; 
return  K; 
end  list_si2e; 


--  checking  the  in_degree  of  the  successors  of  the 
—  Tassigned  step  this  works  with  deadline 
--  heuristic. 

procedure  CHECK_IN_DEGREE ( 

STEP,  REQUEUE  ,  LIST  :  in  out  LINK; 
finish_t  :  in  natural)  is 

POSITION  :  LINK  ;*  LIST; 

PREVIOUS  :  LINK  :=  null  ; 
t  :  set  STEP . SUCCESSORS ; 

tl:  set; 
k  :  natural ; 

FOUND  :  boolean  ;=  FALSE; 
begin 

if  size{t)  /=  0  then 
while  POSITION  /=  null  loop 
k  ;=  POSITION. STEP_ID; 
if  member (k,  t)  then 
if  POSITION. EARLIEST_START_TIME  < 

f inish_t 

then  POSITION. EARLIEST_START_TIME  := 

f inish_t ; 

end  if; 

POSITION. IN^DEGREE  :=  POSITION. IN^DEGREE  ■  1 

if  POSITION. IN_DEGREE  =  0 

then 

INSERT_PENDING_ORDER_START_TIME  ( R_QUEUE , 

POSITION) ; 

POSITION  :=  POSITION. NEXT; 

else 
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PREVIOUS  :=  POSITION; 

POSITION  :=  POSITION, NEXT, 
end  if; 
else 

PREVIOUS  :=  POSITION; 
POSITION  :=  POSITION. NEXT; 
end  if; 
end  loop; 
end  if; 

end  CHECK.IN.DEGREE; 


--  checking  the  in_degree  of  the  successors  of  the 
--  assigned  step 

--  This  works  with  start  time  heuristic, 

procedure  CHECK_IN_DEGREE_1  (STEP,  LIST  :  in  out  LINK; 

REQUEUE  :  in  out  LIST_VECTOR; 
finish_t  :  in  natural)  is 

POSITION  :  LINK  :*  LIST; 

PREVIOUS  :  LINK  :=  null  ; 
t  :  set  :=  STEP . SUCCESSORS ; 
tl:  set; 
k,  kl  :  natural; 

FOUND  :  boolean  :=  FALSE; 
begin 

if  si2e(t)  I-  0  then 

while  POSITION  /»  null  loop 
k  ;*  POSITION. STEP_ID; 
if  member (k,  t)  then 

if  POSITION. EARLIEST_START_TIME  < 
finish_t 

then  POSITION . EARLIEST_START_TIME 
:*  finish.t; 

end  if; 

POSITION. IN_DEGREE  :»  POSITION . IN_DEGREE  -  1; 
if  POSITION. IN^DEGREE  =  0 
then 
kl  :  = 

EXPERTISE_LEVEL’ POS{ POSITION. EXP_LEVEL)  +  1; 
INSERT_ORDER_START_TIME  (REQUEUE (kl ) ,  POSITION); 

POSITION  :»  POSITION. NEXT; 

else 

PREVIOUS  :=  POSITION; 
POSITION  ;=  POSITION. NEXT; 
end  if; 
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else 

PREVIOUS  :=  POSITION; 
POSITION  :=  POSITION. NEXT; 
end  if; 
end  loop; 
end  if; 

end  CHECK_IN_DEGREE_1 ; 


--  checking  the  in_degree  of  the  successors  of  the 
--  assigned  step.  This  works  with  start  time  heuristic. 

procedure  CHECK_IN_DEGREE_2  (STEP,  LIST  :  in  out  LINK; 

R_QUEUE  :  in  out  LIST_VECTOR; 

finish_t  :  in  natural)  is 

POSITION  :  LINK  :=  LIST; 

PREVIOUS  :  LINK  :*  null  ; 
t  :  set  ;=  STEP . SUCCESSORS ; 
tl:  set; 
k,  kl  :  natural; 

FOUND  :  boolean  :=  FALSE; 
begin 

if  size(t)  /=  0  then 

while  POSITION  /=  null  loop 
k  :=  POSITION. STEP_ID; 
if  member (k,  t)  then 

if  POSITION. EARLIEST_START_TIME  < 
f inish_t 

then  POSITION . EARLIEST_START_TIME 
;=  finish_t; 

end  if; 

POSITION. IN_DEGREE  :=»  POSITION.  IN_DEGREE  -  1; 
if  POSITION. IN_DEGREE  =  0 
then 

kl  :»  EXPERTISB_LEVEL'POS( POSITION. EXP^LEVEL) 

+  1; 

INSERT_ORDER_START_TIME  (R_QUEUE (kl ) ,  POSITION); 

POSITION  :=  POSITION. NEXT; 

else 

PREVIOUS  POSITION; 
POSITION  :*  POSITION. NEXT; 
end  if; 
else 

PREVIOUS  :=  POSITION; 

POSITION  :=  POSITION. NEXT; 
end  if; 
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end  loop; 
end  if; 

end  CHECK_IN_DEGREE_2 ; 


--  checking  the  pending  list  for  ready  steps  of  a 
--  certain  level  and  insert  them  into  the 
--  corresponding  ready_list  according  to  their 
--  deadlines 

procedure  GET_READY_STEPS  ( 

t  , k  :  in  natural; 

LIST  :  in  out  LINK; 

REQUEUE  :  in  out  LIST_VECTOR)  is 

POSITION  :  LINK  :=  LIST; 

PREVIOUS  :  LINK  :=  null  ; 
temp  :  natural ; 

FOUND  :  boolean  :=  FALSE; 
begin 

while  POSITION  /*  null  loop 
temp  ;*  EXPERTISE.LEVEL*  POS  ( POSITION.  EXP..LEVEL) 

+  1; 

if  POSITION.EARLIEST_START_TIME  <=  t  and  temp 

>=  k 

then 

INSERT_0RDER_DEADLINE  (R_QUEUE ( temp) , POSITION) ; 
DELETE_FROM_PENDING_LIST ( LIST, POSITION, 

PREVIOUS) ; 

POSITION  ;=  POSITION. NEXT_PENDING; 
else 

PREVIOUS  :=  POSITION; 

POSITION  :=  POSITION. NEXT_PENDING; 
end  if; 
end  loop; 

end  GET_READY_STEPS; 


--  checking  the  pending  list  for  ready  steps  of  a 
--  certain  level  and  insert  them  into  the 
--  corresponding  ready_list  according  to 
--  their  (deadlines  +  start  times) . 
procedure  GET^READY_STEPS_1  (t  ,k  :  in  natural; 

LIST,  R_QUEUE  :  in  out  LINK)  is 

POSITION  :  LINK  :=  LIST; 

PREVIOUS  ;  LINK  :=  null  ; 

temp  :  natural; 
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FOUND  :  boolean  :=  FALSE; 
begin 

while  POSITION  /=  null  loop 
temp :  =  EX^’ERTISE.LEVEL  •  POS  ( POSITION .  EXP_LEVEL)  ; 
if  POSITION. EARLIEST_START_TIME  <=  t  and  temp  =  k 
then 

INSERT_ORDER_MIXED  (R_QUEUE.  POSITION) ; 
DELETE_FROM_PENDING_LIST (LIST. POSITION, 

PREVIOUS ) ; 

POSITION  :=  POSITION. NEXT_PENDING; 
else 

PREVIOUS  :=  POSITION; 

POSITION  :=  POSITION. NEXT_PENDING; 
end  if; 
end  loop; 

end  GET_READY_STEPS_1 ; 


—  checking  the  pending  list  for  ready  steps  of  a 
--  certainlevel  and  insert  them  into  the 
--  corresponding  ready^list  according  to  their 
--  LAXITY. 

procedure  GET_READY_STEPS_2  (t  ,k  :  in  natural; 

LIST,  R_QUEUE  ;  in  out  LINK)  is 


POSITION  :  LINK  :=  LIST; 

PREVIOUS  :  LINK  :=  null  ; 
temp  :  natural ; 

FOUND  :  boolean  :=  FALSE; 
begin 

while  POSITION  /*  null  loop 
temp:= 

EXPERTISE.LEVEL’ POS  ( POSITION.  EXI*_LEVEL)  +  1; 
if  POSITION. EARLIEST_START_TIME  <=  t  and  temp  =  k 
then 

INSERT_0RDER_LAX1TY  (R_QUEUE.  POSITION) ; 
DELETE_FROM_PENDING_LIST (LIST. POSITION, 

PREVIOUS ) ; 

POSITION  :=  POS ITI ON. NEXT_i ENDING; 
else 

PREVIOUS  :=  POSITION; 

POSITION  :=  POSITION. NEXT_PENDING; 
end  if; 
end  loop; 

end  GET_READY_STEPS_2 ; 
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--  get  the  top  steps  in  the  ready  list  and 
--  insert  them  into  the  corresponding  ready_list 
--  according  to  their  deadlines 

procedure  GET_READY_STEPS  (LIST  :in  out  LINK; 

R_QUEUE  :in  out 

LIST_VECTOR)  is 

POSITION  :  LINK  :=  LIST; 

PREVIOUS  :  LINK  :=  null; 
temp  :  natural; 
tempi  :  natural; 
begin 

if  POSITION  /=  null  then 

temp  :=  POSITION. EARL I EST_START_TIME; 
end  i f ; 

while  POSITION  /=  null  and  then 
POSITION. EARLIEST_START_TIME  =  temp  loop 
tempi  := 

EXPERTISE_LEVEL*  POS ( POSITION. EXP_LEVEL) 
-^1; 

INSERT_ORDER_START_TIME  ( R_QUEUE ( t empl )  , 

POSITION) ; 

DELETE_FROM_PENDING_LIST ( LIST, POSITION, 

PREVIOUS) ; 

POSITION  :=  POSITION. NEXT_PENDING; 
end  loop; 

end  GET_READY_STEPS; 


--  get  the  top  steps  in  the  ready  list  and 
--  insert  them  into  the  corresponding  ready_list 
--  according  to  their  (deadlines  +  start  times) . 

procedure  GET_READY_STEPS_1  (LIST  :in  out  LINK; 

R_QUEUE  :  in  out  LIST_VECTOR)  is 

POSITION  :  LINK  :=  LIST; 

PREVIOUS  :  LINK  :=  null ; 
temp  :  natural; 
tempi  :  natural; 
begin 

if  POSITION  /=  null  then 

temp  POSITION. EARLIEST_START_TIME  ; 
end  if; 
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while  POSITION  /=  null  and  then 

POSITION. EARLIEST_START_TIME  =  temp  loop 
tempi  := 

EXPERTISE_LEVEL • POS { POSITION . EXP_LEVEL ) 

1; 

INSERT_ORDER_MIXED  ( R_QUEUE (tempi ) . 

POSITION) ; 

DELETE_FROM_PENDING_LIST(LIST, POSITION, 

PREVIOUS) ; 

POSITION  :=  POSITION. NEXT_PENDING; 
end  loop; 

end  GET_READY_STEPS_1 ; 


--  get  the  top  steps  in  the  ready  list  and 
--  insert  them  into  the  corresponding  ready^list 
--  according  to  their  Laxity. 

procedure  GET_READY_STEPS_2  (LIST  : in  out  LINK; 

REQUEUE:  in  out  LIST_VECTOR)  is 


POSITION  :  LINK  :=  LIST; 

PREVIOUS  :  LINK  :=  null; 
temp  :  natural; 
tempi  :  natural; 
begin 

if  POSITION  t-  null  then 

temp  :*  POSITION. EARLIEST_START_TIME  ; 
end  if; 

while  POSITION  /=  null  and  then 

POSITION. EARLIEST_START_TIME  =  temp  loop 
tempi  := 

EXPERTISE_LEVEL ' POS ( POSITION . EXP_LEVEL) 

+  1; 

INSERT_ORDER_LAXITY  ( R_QUEUE ( tempi ) , 

POSITION) ; 

DELETE_FROM_PENDING_LIST ( LIST, POSITION, 

PREVIOUS) ; 

POSITION  :=  POSI'T’ION.NEXT.PENDING; 
end  loop; 

end  GET_READY_STEPS_2 ; 


procedure  SUGGEST_DEADLINE_SLIP(STEP  :  in  out  lin)<; 

VALUE  :in  natural)  is 


answer  ; character  :=  'n'; 
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begin 

put ( 'in-fecsible  schedule:  step  #  "); 
test_io_pkg.put  {STEP. STEP^ID) ;  new_line; 
put { 'suggested  deadline  should  be  >=  '); 
test_io_pkg.put  (VALUE);  new_line; 
put  (“Would  you  like  to  change  it?  Answer (y/n)  ■)  ; 
get (answer) ;new_line; 
if  answer  3  'y  or  answer  3  'Y* 
then 

put  (“Enter  the  new  Deadline  “); 
get  (STEP.deadline) ; 

STEP.DEADLINE^CHANGE  :=  TRUE; 

else 

put_line( “INFEASIBLE  SCHEDULE'); 
end  if; 

end  SUGGEST_DEADLINE_SLIP; 


—  checking  the  feasibility  of  the  schedule  with 
--  each  step  in  the  ready  queue 

procedure  STRONGLY_FEASIBLE  (REQUEUE  :  in  LINK; 

MATRIX  :  in 

DESIGNER_MATRIX ; 
D_VECTOR  :  in  vector; 
MAX_LEVEL  :  in  natural; 
FEASIBLE  :  in  out  boolean  )  is 
CURRENT  ;  LINK  :3  REQUEUE  ; 

PREVIOUS  :  LINK  null; 
temp,  tempi  :  natural; 

J  :  natural  is  i; 

L  :  natural  :s  i; 

MIN  :  natural  :=0  ; 
begin 

FEASIBLE  :»  TRUE  ; 

while  CURRENT  /s  null  and  FEASIBLE  loop 
LEVEL^MINMUM 

( MATRIX , CURRENT . EXP_LEVEL , MAX_LEVEL , 
D_VECTOR,L.J  ); 
put_line  ("  pass  10  “); 

MIN  :=  MATRIX(L,J)  ; 

if  MIN  >3  CURRENT. EARLIEST_START_TIME 
then  temp  MIN; 
else  temp  := 

CURRENT . EARLIEST_START_TIME ; 

end  if; 
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temp  :=  temp 

CURRENT . ESTIMATEP_DURATION; 

IF  temp  >  CURRENT. DEADLINE 
then 

SUGGEST_DEADL1NE_SLIP (CURRENT, temp) ; 
--  FEASIBLE  :=  FALSE; 
end  if; 

if  temp  >  CURRENT. DEADLINE  then 
FEASIBLE  :=  FALSE; 

end  if; 

PREVIOUS  :=  CURRENT  ; 

CURRENT  :=  CURRENT . NEXT_READY  ; 
end  loop; 

end  STRONGLY.FEASIBLE; 


--  Assign  a  step  to  a  designer  according  to  its  deadline 
--  and  its  expertise  level 

procedure  ASSIGN_STEP  (R_QUEUE  :  in  out  LIST_VECTOR; 

LIST  :  in  out  LINK; 

MATRIX  :  in  out 


K,  finish 
MIN  :  natural 
MINI:  natural; 
J  :  natural 
temp  ;  natural 
tempi  :  link  : 
begin 


DESIGNER^MATRIX ; 


ROW_LENGTH 

M,N 

L 

SCH 

done 

:  natural; 

:=  MATRIX (M,N) ; 

:*  1; 

:=  0; 

=  R_QUEUE(L); 


:  in  vector; 

:  in  out  natural; 

:  in  natural; 

:  in  out  LINKl; 
:  out  boolean  )  is 


done  ;»  TRUE; 


K  :  = 

EXPERTISE_LEVEL '  POS  ( tempi .  EXP_LEVEL)  i-  1  ; 
J  :=  ROW_MINMUM (MATRIX,  tempi . EX P_LEVEL, 
ROW_LENGTH) ; 
if  j  /=  1000  then 

MINI  :=  MATRIX (K,J); 
else  MINI  :*  1000; 
end  if; 

if  MINI  <=  tempi. EARLIEST_START_TIME 
then 


t  emp  : =  t  emp 1 . EARL I EST_START_TIME ; 
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finish  :=  temp  + 

tempi . ESTIMATED^DURATION; 
MATRIX  (K,J):=  finish; 

M  :=  K; 

N  ;=:J; 

CREATE_SCHEDULE_RECORn  tempi .  STEP_ID t emp , 
finish, J, tempi .EX P_LEVEL, 
EXPERTISE_LEVEL'VAL(K-1) ) ; 
INSERT_0RDER_START_T1ME ( SCH , 
NEW_S_RECORD) ; 

DELETE_FROM_READY_QUEUE ( REQUEUE ( L) ) ; 
elsif  I  (M  >  K)  and  then  (R_QUEUE (M) /=  null)  and  then 
(REQUEUE (M) . EARLIEST_START_TIME  <=  MIN))  then 
done  : =  FALSE ; 

else 

if  MIN  >s  tempi. EARLIEST_START_TIME 
then  temp  :*  MIN; 

elsetemp  :=  tempi .EARLIEST_START_TIME; 
end  if; 

finish  :=  temp  +  tempi .ESTIMATED.DURATI ON; 

MATRIX  (M,N):=  finish; 

CREATE_SCHEDULE_RECORD  ( tempi . STEP_ID . 
temp,  finish, N, tempi .EXP_LEVEL, 
EXPERTISE_LEVEL'VAL{M-1) ) ; 

INSERT_ORDER_START_TIME ( SCH ,  NEW_S_RECORD ) ; 
DELETE_FROM_READY_QUEUE(R_QUEUE(L) ) ; 
end  if; 

end  A3SIGN_STEP; 


--  reset  the  step  list  and  the  schedule  for 
--  incrementing  the  schedule 
—  with  new  steps  at  certain  time 
procedure  RESET_FOR_RESCHEDULING ( 

d_list  ;  in  out  D_LINK; 

LIST  :  in  out  LINK; 
MATRIX  :  in  out 

des i gner_ma  t  r ix ; 
d_vector  :  in  vector)  is 

M,N, index,  length  :  natural; 

step_id,  finish_t  :natural; 
designer  :  stringd . .  16)  . 
data_file2  :  FILE_TYPE; 

CURRENT  :LINK; 
begin 

OPEN(data_file2,  IN_FILE,  "tempS"); 

WHILE  not  END_OF_FILE(data_file2)  loop 
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get (data_file2, step_id) ; skip_line (data_f ile2) ; 
test_io_pkg.put (step_id) ; 
get (data_f ile2, f inish^t) ; 

test_io_i.kg.put  (finish_t)  ; 
skip_line(data_file2) ; 
get_line {data_f ile2 , designer,  length) ; 
for  i  in  length+1..16  loop 
designer (i)  :=‘  ' ; 

end  loop; 
put (designer) ; 
new_line; 

skip_line (data_f ile2 ) ; 

CURRENT  :s  LIST; 

while  CURRENT  /=  null  loop 

i f  member ( step_id, CURRENT . PREDECESSORS ) 
then 

CURRENT . IN_DEGREE : =  CURRENT . IN_DEGREE- 1 ; 
if  CURRENT. EARLIEST_START_TIME  <finish_t 
then  CURRENT. EARL I EST_START_TIME  := 

f inish_t ; 

end  if; 
end  if; 

f ind_designer_position (d_list, index, 
designer) ; 

if  index  <=d_vector (1) 
then  M  :=  1; 

N  :=  index; 

elsif  index  >  d_vector(l)  and  index 
<= (d_vector ( 1 ) +d_vector (2 ) ) 
then  M  :=  2; 

N  : =  index  -  d_vector ( 1 ) ; 
elsif  index  >  (d_vector(l)+  d_vector(2)) 
then  M  :=  3; 

N  ;=  index  -  (d_vector ( 1 ) +  d_vector (2 ) ) ; 
end  if; 

if  MATRIX  (M,N)<finish_t 
then 

MATRIX  (M,N) :=finish_t; 
end  if; 

CURRENT  : =  CURRENT . NEXT ; 
end  loop; 
end  loop; 

CLOSE {data_file2)  ; 

DELETE ( da ta_file2)  ; 
exception 

when  NAME_ERROR=> 
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put_line(‘No  original  schedule"); 
end  RESET_FOR_RESCHEDULING; 


--  Search  for  target  step.  Return  the  position  and 
--  previous  if  found. 

procedure  FIND_DESIGNER_POSITION(HEAD  :  in  DELINK; 

D^INDEX  :  out  natural; 
d_name  :  in  string)  is 
POSITION  :  D_LINK  :=  HEAD  ; 

K  ;  natural  ;=1; 
begin 

while  POSITION  /=  null  and  then  POSITION. D_name  /  = 

d_name  loop 

POSITION  :=  POSITION. NEXT  ; 

)c  )c+l; 
end  loop  ; 

D_INDEX  :=  )c  ; 

end  FIND_DESIGNER_POSlTION  ; 


end  scheduler; 


3.  Main  Programs 
new_ecsji  (Manager^Interface) 


--  Title 
--  Author 
--  Date 
--  Revised 
---  System 
--  Compiler 
--  Description 


Manager_Interface  main  program 
Salah  badr 
25  August  1993 

Suns7 

VerdixAda 


with  ECS_OPERATIONS;  use  ECS_OPERATIONS ; 
with  TEXT_IO;  --  BASIC_NUM_IO; 
use  TEXT_IO;  --  BASIC_NUM_IO; 

--  Main  program. 
pac)^age  ecs_manager  is 


Namel 


:  STRING (1.. 9)  :=  "supportDB" ; 


option 

Name3 

Name4 

Names 

Name  6 

Name? 

Names 

Names 

NameA 

NameB 

NameC 

NameD 

NameE 

a^name 

an_id 

SELECTOR 

Length 

answer 

data_f ile 

data_filel 


STRING ( 1 . . 1 )  ; 

STRING! 1. .64)  ; 

STRING ( 1 . . 64 ) ; 

STRING (1 .  .64)  ; 

STRING!!. .64) ; 

STRING ! 1 . . 64 ) ; 

STRING!! . .64)  ; 

STRING!!. .64) ; 

STRING ! ! . . 64 ) ; 

STRING!! . .64) ; 

STRING!! . .64) ; 

STRING!!. .64) ; 

STRING!! . .64)  ; 

STRING!!. .64)  ; 

STRING ! ! . . 5 ) ; 

natural  : =  0; 

integer; 

character := 'y ' ; 

FILE_TYPE;  --  logical 

FILE_TYPE;  logical 


file  definitions 
file  definitions 


procedure  ECS!; 

end  ecs_manager; 

paclcage  body  ecs^manager  is 


procedure  ECS!  is 

paclcage  nat_io  is  new  integer_io ! natural )  ;  use 

nat_io; 

begin 

put_line ! “ECS  has  been  entered."); 

put ! “Names  =>  “ ) ; 

put_!ine !Name3 ) ; 

put ! "SELECTOR  =>  "); 

put! SELECTOR) ; 

new_!ine; 


case  SELECTOR  is 

--  Show  the  prototypes  in  the  database. 


when  1  =>  --show  prototypes 
option :s*8* ; 

Show_Prototypes {Namel ,  option ) ; 
when  2  =>  --  show  steps 

option:a'‘3"; 

Show_Step INamel, option, Name3 ) ; 
when  3  =>  --  show  step 

option :  = '•2  *  ; 

Show_Step (Namel, option, Name3 ) ; 
when  4  =>  --  show  schedule 

option:  =  “2  * ; 

Show_Schedule (Namel, option) ; 
when  5  =>  — create  prototype 

option: s'l* ; 

put ( “Enter  prototype ‘ s  name :  “); 
get_line (Name3 . Length) ; 
for  i  in  Length+l . . 64  loop 
N2une3  ( i )  : « •  '  ; 
end  loop; 

Create_Prototype (Naunel , option, Name3 )  ; 
put ( “More  subconponents  to  add[answer  Y/ 
N] :  *  )  ; 
get (answer) ; 
skip_line; 

while  answer* 'y'  or  answer* ’Y'  loop 
put (“Enter  component  name:  “ ) ; 
get^line (Names,  Length) ; 
for  i  in  Length-^1 .  .  64  loop 
Names ( i ) :  =  '  ’  ; 
end  loop; 

put (“Enter  parent  component  name:  “); 
get^line (Name? , Length) ; 
for  i  in  Length+1 . . 64  loop 
Name? ( i ) : * '  ’ ; 
end  loop; 

Add_SubComponent (Namel , “ 4 “ , Name3 , 

“ 1 : 1 “ , Names ,"1:1", Name? ) ; 
put ( “More  subcomponents  to  add [answer 
Y/N] :  " ) ; 
get (answer) ; 
skip_lin3; 
end  loop; 

when  6  =>  --create  step 
option : =*1 “ ; 

Create_Step (Namel , option , Name3 , Name4 ) ; 
when  ?  *>  --  edit  step 
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systein_call  ( "mainstep  “&Namel&-  4  "&Name3&‘ 
•iNameEfii-  •&Name4&‘  "iName5&"  •&Name6&‘ 
•tName7&“  ‘&Name8St"  ’•&Name9&*  "&NameA&“ 
*&NameB&‘  ■&NameC&‘  •&NameD&‘  >  temp5‘) 

OPEN(data_file,  IN_FILE, "tempS* ) ; 
get_line (data_f ile, a^name, length) ; 
for  i  in  Length+1..5  loop 
a_naine  ( i )  :  =  ‘  ‘  ; 
end  loop: 

if  a_name(l)  =‘s*  then 

put_designers {Namel ,  "2")  ; 
get_sched_data  (Namel ,  0 * )  ; 
get_sched_data_l (Namel , • 0 “ ) ; 
main(l) ; 

elsif  a_name(l)  ='c‘  then 
put_line { "Cannot  Update  a  Completed  Step") 
elsif  a_name(l)  =’a*  then 
put_line ( "Cannot  Update  an  Abandoned  Step") 
end  if; 

CLOSE (data_f ile) ; 
when  8  =>  —  approve  step 

option : ="c" ; 

Show_Step (Namel , option, Name3 ) ; 
when  9  =>  —  schedule  step 

put_designers (Namel ,  • 2 " )  ; 

get_sched_data (Namel , Name3 ) ; 
get_sched_data_l (Namel, "0 " ) ; 
main(l) ; 

when  10  =>  --  commit  step 

option:="e" ; 

Show_Step (Namel , option, Name 3 ) ; 
when  11  =>  —  suspend  step 

begin 

system_call ( "mainstep  *&Namel&"  i  ■&Name3&"  1  > 

temp" ) ; 

OPEN(data_f ilel ,  IN_FILE, "temp") ; 

WHILE  not  END_OF_FILE(data_filel)  loop 
get_line (data_f ilel , an_id, length) ; 
for  i  in  Length+1..5  loop 
an_id ( i ) :  =  •  '  ; 
end  loop; 

get_line(data_filel,Name4, length) ; 
for  i  in  Length+1..64  loop 
Name4 ( i ) : = •  ' ; 
end  loop; 


352 


auto_mail2  (Naine4,  an_id)  ; 
end  loop; 

put^designers (Namel, "I")  ; 
get_sched_data (Namel , “ 0 “ ) ; 
get_3ched_data_l (Namel , " 0 “ ) ; 
main (0)  ; 

CLOSE (data.filel) ; 
exception 

when  NAME_ERROR=> 

put_line(“No  ready  assignment  for  this 
designer" ) ; 

end; 


when  12  s>  --  abandon  step 
begin 

system_call ( "mainstep  "&Namel&“  i  "iNameli"  5  > 

temp" ) ; 

OPEN (data^fi lei,  IN_FILE, "temp") ; 

WHILE  not  END_OF_FILE(data_filel)  loop 
get_line{data_filel,an_id, length) ; 
for  i  in  Length+1..5  loop 
an_id ( i ) : = '  • ; 
end  loop; 

get_line{data_filel,Name4, length) ; 
for  i  in  Length+1..64  loop 
Name4 ( i ) :  =  *  ' ; 
end  loop; 

auto_mail3 (Name4 , an_id) ; 
end  loop; 

put_designers (Namel ,"2"); 
get_sched_data (Namel , " 0 " ) ; 
get_sched_data_l (Namel , " 0 " ) ; 
main(O) ; 

CLOSE (data_filel) ; 
exception 

when  NAME_ERROR=> 

put_line("No  ready  assignment  for  this 
designer" ) ; 


end; 


when  13  =>  --  remove  transfer  file 

system_call ( *rm  ddbdisplay " ) ; 
when  14  =>  --  add  designer 
option : ="1 " ; 
for  i  in  25.. 64  loop 
Name3 ( i ) : = '  ' ; 
end  loop; 

for  i  in  2 . . 64  loop 
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Name4 {!):='  * ; 
end  loop: 

Add_designer  (Namel ,  option,  Naine3 ,  Naine4 )  ; 
put_designers{Namel, “2*) ; 
get_sched_data (Namel , “ 0 ■ ) ; 
get_sched_data_l (Namel , *  0 • ) ; 
main(O) ; 

when  15  =>  --  show  designers 

option: =“ 2* ; 

Show_designer(Naunel,  option)  ; 
when  16  =>  --  Delete  designer 

option :=“3"; 
for  i  in  25.. 64  loop 
Name3 ( i ) :  =  *  * ; 
end  loop; 

--  if  status=  busy,  reschedule 
Delete_designer (Namel , option, Name3 ) ; 

— and  reschdule 
if  Name4(1..4)  *  "Busy-  then 
put_line( "NOTICE;  The  Designer  just 
deleted  was  busy-); 

put_line("  RESCHEDULING  his/her  tas)<s  . " ) 
get_sched_data_2 (Namel , Name3 ) ; 
system^call ( "mainsched  •&Namel&"  7  -iNamel) 
put_designers (Namel , -  2 " ) ; 
get^sched_data_l (Namel ,  Name3 )  ; 
main(O) ; 
end  if; 

when  17  =>  --  Change  expertise  level 

option : ="4 " ; 
for  i  in  25., 64  loop 
Name3 ( i ) : * •  ' ; 
end  loop; 

for  i  in  2 . . 64  loop 
Name4 ( i ) : = ■  ' ; 

end  loop; 

Change_exp_level (Namel , option, Name3 , Name4 ) 
put_designers (Namel , " 2 " ) ; 
get_sched_data (Namel , " 0 " ) ; 
get_sched_data_l (Namel , " 0 " ) ; 
main(l) • 

--  exception  handling  for  selector  case, 
when  others  => 
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pUtC  BAD  CHOICE.  PLEASE  TRY  AGAIN*); 
new_liiie  ; 
end  case; 

end  ECSl ; 


begin 
null  ; 


end  ecs_nianager; 

Designer_lnterface.a  * 

—  Title 
--  Author 
--  Date 
--  Revised 
--  System 
--  Compiler 
--  Description 


Designer_Interface  program 
Salah  badr 
25  September  1993 

Suns? 

VerdixAda 


with  ECS_OPERATIONS ;  use  ECS^OPERATIONS ; 
with  TEXT_IO;  --  BASIC_NUM_10; 
use  TEXT_IO;  BASIC_NUM_IO  ; 

--  Main  program. 

procedure  DESIGNER_INTERFACE  is 

package  nat_io  is  new  integer_io (natural ) ;  use  nat_io; 


Namel 

STRING ( 1 . . 9 ) 

=  ‘supportDB*; 

option 

STRING (1 . . 1 ) 

Name  3 

STRING (1. .64) 

Name4 

STRING (1. .64) 

Name  6 

STRING (1 . .64) 

Names 

STRING (1. .64) 

Name? 

STRING (1. .64) 

an_id 

STRING ( 1 . . 5 ) ; 

the_time 

string ( 1 . . 14 ) ; 

SELECTOR 

natural  :=  0; 

Length 

integer; 

data^f ile 

FILE_TYPE; 

--  logical  file  definitions 

data_f ilel 

FILE_TYPE; 

--  logical  file  definitions 

answer 

character  ;='y 

§ 

--  DISPLAY  THE  MAIN  MENU. 
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procedure  DESIGNER_MENU  is 
begin 

new_line; 

set_col(25);  put ( "DESIGNER  MENU" ) ;  new_line; 
set_col ( 25 ) ;  put ("=============*) ;  new_line(2) 

set_col(5);  put(“[l]  Show  Prototypes"); 
new_line; 

set_col(5):  put ("(2)  Show  Component  Subtree") 
new_line; 

set_col(5);  put(*[")  r  low  Steps"); 
new_line; 

set_col(5);  put("(4]  Show  Step"); 
iew_line; 

set_col(5);  put ( ■  .  1  Create  Prototype"); 
new_line; 

set_col(5);  put ("[6]  Create  Step"); 
new_line; 

set_col(5);  put ("(6)  Create  Substep"); 
new_line; 

set_col(5);  put {"(7)  Commit  Substep"); 
new_line; 

set_col(5);  put  ("[8]  Retrieve  Vers''on"); 
new_line; 

set_col(5);  put ("[9]  Retrieve  Spec  File"); 
new_line; 

set_col(5);  put ("(10)  Retrieve  Imp  File"); 
new_line; 

set_col(5);  put ("[11]  Show  Schedule"'; 
new_line; 

set_col(5);  put {*[12]  Quit");  new_line(3); 
set_col(5);  put ("Enter  the  number  of  your  choice 


end  DESIGNER_MENU  ; 


begin 

!<-  p 
begin 

system_call  ( "mainstep  "&NamelSt"  h  >temp"); 
OPEN(data_file,  IN_FILE, "temp" ) ; 
get_line (data_f ile, an_id, length' ; 
for  i  in  Length+1..5  loop 
an_id ( i )  :  =  '  ‘  ; 
end  loop; 

if  an_id(l)  ='F'  then 
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get_l  me  (data_f  1  le,  Name4 ,  length,  ; 
for  1  in  Lfength>1..64  loop 
Name4 ( i )  :  =  '  ‘  ; 

end  loop; 

system_cali ( "mkdir  "&Name4); 
get_line (data_f lie. an_id, length) ; 
for  1  in  Length<-1..5  loop 
an_id ( i )  :  =  ■  '  ; 

end  loop; 

3ystem_cal 1 ( “mainstep  *&Namelfii‘  g  ■&an_id) ; 
end  1 f ; 

CLOSE(data_file) ; 
system_call ( “ rm  temp*); 
end; 
loop 

DESIGNER_MENU  ; 

get (SELECTOR) ;  skip_line  ; 
case  SELECTOR  is 

--  Show  the  prototypes  in  the  database, 
when  1  =>  --  Show  Prototypes 

option :  =  *8* ; 

Show_Prototypes (Namel , option ) ; 
system_call ( “more  ddbdisplay* ) ; 
when  2  =>  --  Show  Component  Subtree 

opt  ion :  =  *3*; 

put (‘Enter  prototype’s  name:  *); 
get_line (Name3, Length) ; 
for  1  in  Length+1..64  locp 
Name  3 ( i ) :  =  '  ’ ; 

end  loop; 

put ( ‘Enter  variation  and  version [var : ver ] ;  " ) 
get_l  me  (Names,  Length)  ; 
for  1  m  Length+1 . . 64  loop 
Names ( i ) : = '  * ; 
end  loop; 

put (‘Enter  component  name:  ‘ ) : 
get_l  me  (Names,  Length)  ; 
for  1  m  Leng-h*:..S4  leer. 

r.'ameS  ;  i )  ;  =  '  '  ; 

end  Ic.tp; 

gener  al_f  unct  ion  (Namel ,  opt  ion,  Name3  ,  Nair.eS,  Na.meS  )  ; 
when  3  =»  --  Show  Steps 

cpt icn : = • 3 ' ; 

put (‘Enter  Step  status  or  all  to  see  all  the 
steps :  ’ i ; 
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get_line (Name3 , Length) ; 
for  i  in  Length+1..64  loop 
Naine3  (  i )  :  =  '  ‘  ; 
end  loop; 

Show_Step (Name! , opt  ion, Name3 ) ; 
system_call ( "more  ddbdisplay* ) ; 
when  4  =>  --  Show  Step 

option; ="2* ; 
put ("Enter  step^id;  “ ) ; 
get_iine (Name3 , Length)  ; 
for  i  in  Length+1..64  loop 
Name3 ( i) : = '  ' ; 
end  loop; 

Show_Step  (Namel ,  opt  ion,  Naine3 )  ; 
systein_call  ( “more  ddbdisplay* )  ; 
when  5  =>  --  Create  Prototype 

option : =“ 1 ■ ; 

put (“Enter  prototype's  name:  “); 
get_line (Name3 , Length) ; 
for  i  in  Length+1 . . 64  loop 
Name3 ( i ) :  =  *  * ; 
end  loop; 

Create_Prototype  (Namel ,  opt  ion,  NameJ) )  ; 

put (“More  subcomponents  to  add(answer 
Y/NJ :  “); 
get (answer) ; 
s)cip_line; 

while  answers 'y'  or  answers ‘Y*  loop 
put (“Enter  component  name;  * ) ; 
get_l ine (Names, Length) ; 
for  i  in  Length-t-1 .  .  64  loop 
Names ( i )  :  =  '  ’  ; 

end  loop; 

put (“Enter  parent  compontnc  name;  “); 
get_line (Name7, Length) ; 
for  i  in  Length-*- 1 .  .  64  loop 
Name7 (!):=■  • ; 

end  loop; 

Add_SubComponfer.t  ( Name!  Narr.ei  , 

”  1  :  ]  ■ ,  Names  ,  "  1  : 1 ' ,  r.'dme7  }  ; 
put .'More  subcomponents  to  addlansw.T 
Y/N];  “); 

yet ( answer ) ; 
s)<ip_line; 
end  loop; 

v/hen  6  --  create  substep 
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option:=*b* ; 

put { ‘Enter  parent  step_id:  “); 
get_line (Name3 . Length) ; 
for  i  in  Length+1..64  loop 
Name3 ( i ) :  =  *  ' ; 
end  loop; 

put (‘Enter  primary  input:  ‘); 
get_line(Name4, Length) ; 
for  i  in  Length+1..64  loop 
Name4 ( i ) . = '  ‘ ; 
end  loop; 

put(‘Enter  Estimated  duration;  “); 
get_line (Names, Length) ; 
for  i  in  Length+1..64  loop 
Names ( i ) ; = ‘  ‘ ; 
end  loop; 

create_substep (Namel , option, Name3 , 

Name4, Names ) ; 
put_designers (Namel , ‘2’) ; 
get_sched_data (Namel . •0‘) ; 
system_call ( ‘cat  temps  temp8  >  temp9‘); 
system_call ( ‘rm  temps  temp8‘); 
system_call ( *mv  temp9  temps'); 
get_sched_data_l ( Namel ,‘0‘); 
main ( 0 ) ; 

Show_Schedule (Namel ,'2'); 
system_call ( ‘more  ddbdisplay ‘ ) ; 
when  7  =>  --  commit  substep 

begin 

option : =*d' ; 
put (‘Enter  step_id:  *); 
get_line (Name3 , Length) ; 
for  1  1".  Length*!  .  .  64  loop 
Name3 ( i ) : = ’  ' ; 
end  1 oop ; 

Show^Scep (Namel , option, Name3 ) ; 
get_current_t ime ( the_t ime) ; 
remove_3t  ep_f  rom_schedu  le  '  Narel ,  '  f  “  ,  N  irr.vl 

t  he_t ime ) 

OPEN (data_fi lei,  IN_F:LC, *temp4’ / ; 
get_l  me  (data_f  i  lei ,  an_id,  length  /  ; 
for  1  in  Length*1..5  loop 
an_id ( 1 ) : = ■  ' ; 

end  loop; 

if  an_id{l)  =‘N‘  then 
WHILE  not  ENr!_OF_FILE(data_f  1  lei  /  loop 
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get_line (data_f ilel, an^id, length) ; 
for  i  in  Length+1 . . 5  loop 
an_id { i ) :  =  *  * ; 
end  loop; 

get_line(data_filel,Nanie4,  length)  ; 
for  i  in  Length+1 . . 64  loop 
Naine4  ( i )  :  =  ‘  '  ; 
end  loop; 

update_tiine(Namel,  *5* , an_id,  the_time)  ; 
auto_inail  {Naine4,  an_id)  ; 

Change_status (Namel , “ 5  * ,  Name4 ) ; 
general_update  (Namel ,  “7* ,  an_id,  *3  ■■ )  ; 
end  loop; 

elsif  an_id(l)  =*R'  then 
put_designers (Namel , *  2  * ) ; 
get_sched_data (Namel, “0*) ; 
get_sched_data_l (Namel , " 0  * ) ; 
main (0)  ; 

Show_Schedule (Namel , *  2 ‘ ) ; 
system_call ( 'more  ddbdisplay' ) ; 
end  if; 

CLOSE {data_filel) ; 


exception 

when  NAME_ERROR=> 

put_line('No  ready  assignment  for  this 
designer' ) ; 

end; 

when  8  =>  --  dump  version 

option: = 'S' ;  --  option=6  for  dump  compo. 

put ( " Enter  prototype • s  name :  " ) ; 
get_iine (Name3 , Length) ; 
for  i  in  Length+1..64  loop 
Name3 ( i ) : = '  ' ; 
end  loop; 

put ('Enter  component  name:  "); 
get_line f Names, Length) ; 
for  i  in  Length-*-!  .  .  64  loop 


Names ( i ) : = ' 


end  loop; 

pur ('Enter  variation  and  version:  ’); 
get_iine (Name6 , Length) ; 
for  i  in  Length+1..5  loop 
Name6 ( i ) : = '  ' ; 
end  loop; 

Dump_vers ion (Namel , opt  ion, Name! . NameS , Name6 ) 
vd.en  9  =>  --  dump  spec  file 
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option: =*a‘ ; 

put {'Enter  prototype's  name:  "); 
get_line (Name3 , Length) ; 
for  i  in  Length+1..64  loop 
Name3 ( i ) : = ‘  ' ; 
end  loop: 

put (“Enter  component  name:  "); 
get_line (Names. Length) ; 
for  i  in  Length+1..64  loop 
Names ( i ) : = '  ‘ ; 
end  loop; 

put("Enter  variation  and  version:  “); 
get_line (Names, Length) ; 
for  i  in  Length+1 . . S  loop 
Names (i) :='  • ; 
end  loop; 

Dump_version (Namel , option, Name 3 , NameS , NameS ) 
when  10  =>  --  dump  Imp.  file 

option; ='b' ; 

put (“Enter  prototype's  name;  “); 
get_line (Name3, Length) ; 
for  i  in  Length+1.. S4  loop 
Name3 (i) :='  ' ; 
end  loop; 

put (“Enter  component  name:  "); 
get_line (Names, Length) ; 
for  i  in  Length+1.. S4  loop 
Names ( i ) : = '  ' ; 
end  loop; 

put (“Enter  variation  and  version:  "); 
get_line (Names. Length) ; 
for  i  in  Length+1.. S  loop 
Names { i ) : = '  ' ; 
end  loop; 

Dump_vers ion (Namel , option. Name3 , NameS , NameS ) 
when  11  =>  --  show  schedule 

option :=“2“; 

Show_Schedule (Namel , opt  ion) ; 
system_call ( “more  ddbdisplay ) ; 
when  12  => 

put (“thank  you  ....  Bye  ...Bye“); 
new_line  ; 
exit  ; 

--  exception  handling  for  selector  case, 
when  others  => 
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putC  BAD  CHOICE.  PLEASE  TRY  AGAIN"); 
new_line  ; 
end  case; 
end  loop; 

end  DESIGNER_INTERFACE; 


ddb_Interface.a  (Tae  for  manager  interface) 


--  Title 
--  Author 
--  Date 
--  Revised 
--  System 
--  Compiler 
--  Description 


Tae  program  for  manager  interface 
Sal ah  badr 
25  October  1993 

Suns7 

VerdixAda 


with  tae;  use  tae; 

with  X_Windows; 

with  text_io;  use  text_io; 

with  ecs_manager;  use  ecs^manager; 

procedure  ddb_interface  is 

--  FILE:  ddb_interface_support_spec . a 
--  Supporting  procedures  for  ddb_interf ace 
Including  event  handling  routines. 

package  ddb_interface_support  is 


package  taefloat_io  is  new  text_io . f loat_io  (taefloat); 
package  taeint_io  is  new  text_io. integer_io ( taeint ) ; 

package  int_io  is  new  text_io. integer_io ( integer) ;  use 
int_io; 

procedure  initializePanels  (file  :  in  string);  --  NOTE: 
params  changed 

procedure  CLEAR_STEP_INFO; 

--  BEGIN  EVENT  HANDLERS 
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procedure  inain_selection_l  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  editstep_base_version  (info  ;  in 
tae_wpt . event_context_ptr) ; 
procedure  editstep_pri_input  (info  :  in 
tae_wpt .event_contexC_ptr) ; 
procedure  editstep_predecessors  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  editstep_prioricy  (info  ;  in 
tae_wpt . event_context_ptr) ; 
procedure  editstep_exp_level  (info  ;  in 
tae_wpt . event_context_ptr) ; 
procedure  editstep_deadline  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  editstep_est_duration  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  editstep_sec_input  (info  ;  in 
tae^wpt . event_contexC_ptr) ; 
procedure  editstep_af fected  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  editstep_return  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  editstep_apply_step  (info  :  in 
tae_wpt .event_contexc_ptr) ; 
procedure  editstep_cancel_step  (info  :  in 
tae^wpt . event_context_ptr) ; 
procedure  editteain_naine  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  editteain_ex_opt  (info  :  in 
tae_wpt .event_context_pcr) ; 
procedure  editteain_d_cancel  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  edittean\_designers  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  editteain_selection_3  (info  ;  in 
tae_wpt .evenc_context_ptr) ; 
procedure  confirni_yes  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  confirm_no  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  s_select_s_select_itein  (info  :  in 
tae_wpt . event_context_ptr) ; 
procedure  showstep_s_select_item  (info  :  in 
tae_wpt . event_context jptr) ; 
procedure  show_step_nu.Tiber  (info  :  in 
Cae_wpt . event_context_ptr) ; 
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procedure  show_show_f inish  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  textl_display_done  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  textl_text_item_l  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  steptype_type_selection  (info  :  in 
tae_wpt .event_context_ptr) ; 
procedure  editnuin_s_select_item  (info  :  in 
tae_wpt .event_context_ptr) ; 

--  END  EVENT_HANDLERs 

end  ddb_interface_support ; 

--  ENDFILE:  ddb_interface_support_spec . a 


use  ddb_interf ace_support ; 
use  tae.tae_inisc; 

theDisplay  :  X^Windows .Display ; 
user_ptr  :  tae_wpt .  event_context_jptr; 
inain_info  :  tae_wpt .  event_context_ptr ; 
editstep_info  :  tae_wpt.event_contex._ptr; 
editteam_info  :  tae_wpt .event_context_ptr ; 
confinn_info  :  tae_wpt .event_context_ptr; 
s_select_info  :  tae_wpt . event_context_ptr ; 
showstep_info  :  tae_wpt .event_context_ptr; 
show_info  :  tae_wpt .event_context_pt^; 
textl_info  :  tae_wpt .event_context_ptr; 
steptype_info  :  tae_wpt .event_context_ptr; 
editnuln_int■o  :  tae_wpt .event_context_ptr; 
ctype  :  wpt_eventtype; 
wptEvent  :  tae_wpt .wpt_eventptr; 

dummy  ;  boolean;  --  used  to  clear  out  the  wpt  event  queue 

type  activity_selector  is  (editing,  creating) ; 

MAX_DESIGNERS  :  integer  :=  20; 

MAX_SEC_INPUTS  :  integer  :=  20; 

secondary_inputs  :  s_vector ( 1 . .MAX_SEC_INPUTS)  :=  (others 
=>  new  string!! . . 64) ) ; 

af fected_modules  :  s_vector(l. .MAX_SEC_INPUTS)  :=  (others 
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=>  new  string (1 . .64) ) ; 

designer_info  :  s_vector{l. .MAX_DESIGNERS)  :=  (others 
=>  new  string (1 . .64) ) ; 
deadline  :  stringd.  .24)  ; 

designer  :  string ( 1 . .24 ) ; 

start^time  :  stringd  .  .24)  ; 

status  :  stringd  .  .24)  ; 

finish_time  :  string d .. 24 ) ; 

sub^steps  :  string (1 .. 24 ) ; 

predecessors  :  string d .. 24 ) ; 

expert ise_level  :  string d . .24) ; 

designer_status  :  string (1 . .24) ; 

base^versicn  :  string d .. 64) ; 

priinary_input  :  string  (1 ..  64)  ; 

data_file  :  text_io . file_type; 

length  :  integer; 

counter  :  integer; 

temp_string  :  stringd.  .64)  ; 

priority  ;  integer; 

est^duration  :  integer; 

step_nuinber  :  integer; 

editing_or_creating  :  activity_selector ; 


--  FILE:  ddb_interface_support_body .a 

paclcage  body  ddb_interface_support  is 

procedure  initializePanels  (file  :  in  string)  is 

use  tae.tae_co; 
use  tae .  tae_inisc; 

tinp_info  :  tae_wpt  .event.context.ptr.- 
duitany  :  BOOLEAN ; 

begin 

--  do  one  Co_New  and  Co_ReadFile  per  resource  file 
tinp_info  :=  new  tae_wpt  .event_cor.text  ; 
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Co_New  (0,  tmp_inf o. collect ion ) ; 

--  could  pass  P.ABORT  if  you  prefer 
Co_ReadFile  (tmp_info. collection,  file,  P_CONT) ; 

--  pair  of  Co_Finds  for  each  panel  in  this  resource  file 

main_info  :=  new  tae_wpt.event_context; 

main_info . collection  :=  tinp_info . collection; 

Co_Find  (main_info. collection,  ■*main_V  , 
main_info . view) ; 

Co_Find  {main_info .collection,  "main_f, 
inain_info.  target)  ; 

editstep_info  new  tae_wpt .event_context ; 

editstep_info . collection  :=  tmp_info. col lection ; 

Co_Find  (edicstep_info. collection,  "editstep_v“ , 
editstep_info . view) ; 

Co_Find  (editstep_info. collection,  •editstep_t “ , 
editstep_info. target) ; 

editteain_info  :=  new  tae_wpt .  event_context  ; 

editteain_info .  collection  :=  tinp_inf  o.  col  lection  ; 

Co_Find  (editteam_info. collection,  ‘•editteam_v" , 
editteam_info.view) ; 

Co_Find  (editteain_info. collection,  "editteam.t" , 
editteain_info. target)  ; 

confinn_info  :=  new  tae_wpt.event_context; 

confinn_info . collection  ;=  tmp_info . col lection ; 

Co_Find  (confinn_info .collection,  'conf irTn_v* , 
conf inti_info.view)  ; 

Co_Find  (conf  irm^info. collection,  "conf inn_t , 
conf irm_info. target) ; 

s_select_info  :=  new  tae_wpt .event_context; 

s„select_info . collection  :=  tmp_info . col lection ; 

Co_Find  (s_select_info. collection,  " s_select_v“ , 
s_select_info . view) ; 

Co_Find  (s_select_info .collection,  ■s_select_t " , 
s_select_info. target) ; 

showstep_info  :=  new  tae_wpt.event_context; 

showstep_info . collection  :=  tmp_inf o. collection ; 

Co_Find  (showstep^info. collection,  ■showstep_v" , 
showstep_info . view) ; 

Co_Find  (showstep_info . collection,  * showstep_t " , 
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showstep_inf o . target )  ; 

show_info  : =  new  tae_wpt.event_context; 

show_info .  collection  :=  tinp_info .  col  lection  ; 

Co_Find  (show_info. collection,  “show_v“, 
show_info . view) ; 

Co_Find  (show_info .collection,  ■show_t‘‘, 
show^inf o . target ) ; 

textl^info  :=  new  tae_wpt.event_context; 

textl_info . collection  :=  tmp_info . collection; 

Co_Find  ( textl_info . collection,  ■textl_v*, 
textl_info . view) ; 

Co_Find  (textl_info. collection,  ■textl_t", 
textl_info . target ) ; 

steptype_info  :=  new  tae_wpt . event_context ; 

steptype_info .  collection  :=  tinp_inf  o.  col  lection  ; 

Co_Find  (steptype_info , collection,  "steptype^v* , 
steptype_info.view) ; 

Co^Find  (steptype^info. collection,  "steptype^t • , 
steptype_inf o . target ) ; 

editnum_info  ;*  new  tae^wpt . event_context ; 

editnum_info. collection  :=  tmp_info. collection; 

Co_Find  (editnuin_info.  col  lection,  •editnuin_v* , 
editnun\_info.view)  ; 

Co_Find  (editnuin_info.  col  lection,  "editnuin_t  • , 
editnum^info . target) ; 


--  Since  there  can  now  be  MULTIPLE  INITIAL  PANELS  defined 
from 

--  within  the  TAE  Wor)cBench,  call  Wpt_NewPanel  for  each 
panel 

--  defined  to  be  an  initial  panel  (but  not  usually  all 
the  panels 

--  which  appear  in  the  resource  file) . 


if  main^info .panel_id  =  NULL_PANEL_ID  then 

tae^wpt .Wpt_NewPanel  ("•,  main_info . target , 
main_info . view, 

X_Windows .Null_Window,  main_info, 
tae_wpt .WPT_PREFERRED, 

main_info.panel_id) ; 
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else 


tae_wpt .Wpt_SetPanelState  { 

inain_info.panel_id.  tae_wpt . WPT_PREFERRED) 

end  i f ; 

dummy  :=  Tae_Wpt . Wpt_Pending; 
end  initializePanels; 
procedure  CLEAR_STEP_INFO  is 
begin 

for  i  in  1 .  .20  loop 

secondary_inpuCs (i) .all  := 

a 

af f ected_modules ( i ) . all  := 

a 

end  loop; 

deadline  :=  ■  ■; 

designer  : =  *  •; 

start_time  :=  ■ 

status  ;=  *  *; 

finish_time  :*  ■  •; 

sub_steps  : =  *  "  ; 

predecessors  :=  ■  •; 

expert ise_level  ; 

base_version  := 

a 

M  • 

/ 

primary_input  : = 

a 


temp_string 

a 


priority  :=  0; 

est_duration  ;=  0; 

end  CLEAR_STEP_INFO; 


BEGIN  EVENT_HANDLERs 


procedure  main_selection_l  (info  :  in 

tae_wpt .event_context_ptr)  is 
value  :  array  (1..!)  of  string 

(1. .tae_taeconf .STRINGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  (“Panel  main,  parm  selection_l:  value  =  “) 
tae_vm. Vm_Extract_Count  (info.pann_ptr,  count); 
if  count  <=  0  then 

text_io . put_l ine  ( " none  * ) ; 
else 

tae^vm. Vm_Extract_SVAL  (info .parm_ptr,  1,  valued)); 

text_io.put_line  (valued)); 
end  i f ; 

if  (FALSE)  then  null; 

elsif  s^equal  (valued),  “show  prototypes " )  then 
SELECTOR  :=  1; 

ECSl; 

if  textl_info .panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  ("“,  textl_info . target , 
textl_info . view, 

X_Windows .Null^Window,  textl_info, 
tae_wpt .WPT_PREFERRED, 

t_-xtl_info.panel_id)  ; 

else 

tae_wpt .Wpt_SetPanelState  ( 
textl_info .panel_id,  tae^wpt . WPT_PREFERRED) 
end  if; 

elsif  s_equal  (valued),  “show  steps“)  then  null; 
if  steptype_info.panel_id  =  NULL_PANEL_ID  then 
tae^wpt .Wpt_NewPanei  (““,  steptype_info . target , 
steptype_info . view, 

X_Windows .Null_Window,  steptype_info, 
tae_wpt .WPT_PREFERRED, 

steptype_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  { 
steptype_info.panel_id, 
tae_wpt .WPT_PREFERRED) ; 
end  if; 

elsif  s_equal  (valued),  “show  step  details")  then 
null  ; 
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if  showstep_info.panel_id  =  NULL_PANEL_ID  Chen 
tae_wpt . Wpt_NewPanel  ("*,  showstep_info . target , 
showstep_inf o . view, 

X_Windows . Null_Window,  showstep_inf o, 
tae_wpt .WPT_PREFERRED, 

showstep_info.panel_id) ; 

else 

tae_wpt .Wpc_SetPanelState  ( 
showstep_info . panel_id, 
tae_wpt .WPT_PREFERRED) ; 

end  1 f ; 

Tae_Wpt . Wpt_Set Intg { shows tep_info . panel_id, ■s_sele 
ct_item" , Taeint ( 0 ) )  ; 

elsif  s_equal  (valued),  “show  schedule")  then 

SELECTOR  :=  4; 

ECSl; 

if  textl_info.panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  textl_info . target , 

t ext l_info .view, 

X_Windows .Null_Window,  teytl_info, 
tae_wpt .WPT_PREFERRED, 

textl_info .panei_id) ; 

else 

tae_wpt , Wpt_SetPanelState  ( 

textl_info.panel_id,  tae_wpc . WPT_PREFERRED) ; 

end  i f ; 

elsif  s_equal  (valued),  “create  prototype")  then  null; 
elsif  s_equal  (valued),  "create  step")  then 

editing_or_creating  :=  creating; 

CLEAR_STEP_INFO ; 

if  editstep_info.panei_id  =  NULL_PANEL_ID  then 
tae_wpt .Wpt_NewPanel  ("",  ediCstep_info . target , 
editstep_inf o .view, 

X_Windows .Null_Window,  editstep_inf o, 
tae_wpt .WPT_PREFERRED, 

editsCep_info . panel_id) ; 

else 

tae_wpt . Wpt_SetPanelState  ( 
editstep_info .panel_id, 

•  ae_wpt .WPT_PREFERRED) ; 

end  1 f ; 
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still  need  to  clear  displayed  affected  modules  and 
secondary  inputs 


Tae_Wpt .Wpt_SetSt ring (edit St ep_info . panel_id, “base 
_version" , 

base_version) ; 

Tae_Wpt . Wpt_SetIntg (editstep_inf o . panel_id, “est_du 
ration" , 

Taeint (est_duration) )  ; 

Tae_Wpt .Wpt_SetString(editstep_info .panel_id, "exp_ 
level • , 

expert i se_l evel ) ; 

Tae_Wpt .Wpt_SetIntg(editstep_info.panel_id, “priority" , 

Taeint (priority) ) ; 

Tae^Wpt .Wpt_SetString (editstep_info .panel_id, "desi 
gner* , 

designer) ; 

Tae_Wpt . Wpt_Set String { edi t s tep_info .panel_id, "dead 
line" , 

deadline) ; 

Tae_Wpt .Wpt_SetString (editstep_info.panel_id, "star 
t_t ime ■ , 

start_time) ; 

Tae_Wpt .Wpt_SetString{editstep_info.panel_id, " f ini 
sh_time" , 

finish_time) ; 

Tae_Wpt .Wpt_SetString (editstep_info .panel_id, "pri_ 
input " , 

primary_input ) ; 

Tae_Wpt .Wpt_SetIntg {editstep_info . panel_id, " step_n 
umber" , 

Taeint (0) ) ; 

Tae_Wpt . Wpt_Set St ring (edits tep_info . panel_id, “sub_ 
steps' , 

sub_steps) ; 
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Tae_Wpt . Wpt^SetSt ring (edit St ep_info .panel_id, ‘pred 
ecessors “ , 

predecessors) ; 


elsif  s^equal  (valued),  "edit  step  =>“)  then  null; 
if  editnuin_info . panel_id  =  NULL_PANEL_ID  then 
tae_wpt  .Wpt_NewPanel  (•“,  editnuin_info . target , 
editnum_info . view, 

X_Windows  .Null_Window,  editriuni_inf  o, 
tae_wpt .WPT_PREFERRED, 

editnum_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 
editnuin_info.panel_id,  tae_wpt  .WPT_PREFERRED)  ; 
end  if; 

Tae_Wpt .  Wpt_SetIntg  { editnuin_inf  o  .panel_id,  •s_selec 
t_item“ , Taeint (0) ) ; 

elsif  s_equal  (valued),  'edit  team  *>“)  then  null; 
if  editteam_info.panel_id  =  NULL_PANEL_ID  then 
tae_wpt .Wpt_NewPanel  (■“,  editteam_ir^o . target , 
edi  1 1  eain_inf  o .  view, 

X_Windows .Null^Window,  editteam_info, 
tae^wpt .WPT^PREFERRED, 

editteam^info .panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 
editteam_inf o .panel_id, 
tae_wpt .WPT^PREFERRED) ; 
end  if; 

SELECTOR  :=  13;  --  remove  data  transfer  file 

ECSl  ; 

SELECTOR  :=  15;  --  put  'show  designers'  information  in  data 

transfer  file 

ECSl  ; 

--  read  in  the  designers  from  the  transfer  file  (ddbdisplay) 
into  the  editteam  panel 

text_io.OPEN (data_f ile, 
text_io. IN_FILE, "ddbdisplay") ; 


counter  : =  1 ; 


while  not  end_of_f ile {data_f ile)  loop 


get_line (data_file, designer_info (counter) .all, leng 
th)  ; 

TAE_Wpt . Wpt_SetStringConstraints ( editteam_inf o .pan 
el_id. 

“designers",  Taeint (counter ) , 
designer_ir£o) ; 

counter  :=  counter  1; 

end  loop; 

text_io .CLOSE (data_f ile)  ; 
for  i  in  counter . .MAX^DESIGNERS  loop 
designer_info(i) .all  := 


TAE^Wpt .Wpt_SetStringConstraints (editteain_info .pan 
el_id, 

“designers’,  Taeint (counter) , 
designer_info) ; 

end  loop; 

elsif  s_equal  (valued),  “approve  step")  then 
Selector  :=  8; 

if  s_select_info.panel.id  *  NULL_PANEL_ID  then 
tae^wpt .Wpt_NewPanel  (““,  s_select_info . target , 
s_select_info . view, 

X_Windows .Null_Window,  s_select_inf o , 
tae_wpt .WPT_PREFERRED, 

s_select_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 
s_select_inf o .panel_id, 
tae_wpt .WPT_PREFERRED) ; 

end  i f ; 
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Tae_Wpt . Wpt_Setlntg (s_select_info .panel_id, “ s_sele 
ct_item' , Taeint (0) ) ; 

elsif  s_equal  (valued)  ,  “schedule  step*)  then 
Selector  :=  9; 

if  s_select^info.panel_id  =  NULL_PANEL_ID  then 
tae_wpt .Wpt_NewPanel  (*“,  s_select_info. target, 
s_select_inf o . view, 

X_Windows .Null_Window,  s_select_info, 
tae_wpt .WPT_PREFERRED, 

s_select_inf o .panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 
s_select_info.panel_id, 
tae_wpt .WPT_PREFERRED) ; 

end  if; 

Tae_Wpt .Wpt_SetIntg(s_select^info.panel_id, “s_sele 
ct_item“ , Taeint (0) ) ; 

elsif  s_equal  (valued),  “commit  step*)  then 
SELECTOR  :a  10; 

if  s_select_info.panel_id  *  NULL_PANEL_ID  then 
tae_wpt .Wpt_NewPanel  (““,  s_select_into. target, 
s_select_inf o . view, 

X_Windows .Null^Window,  s_select_info, 
tae_wpt .WPT_PREFERRED, 

s_select_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 
s_select_info.panel^id, 
tae_wpt .WPT_PREFERRED) ; 

end  if; 

Tae_Wpt .Wpt_SetIntg(s_select^info.panel_id, “s_sele 
ct_item“ , Taeint (0) ) ; 

elsif  s_equal  (valued),  “suspend  step*)  then 
SELECTOR  :=  11; 

if  s_select_info.panel_id  =  NULL_PANEL_ID  then 
tae_wpt .Wpt_NewPanel  (“*,  s_select_info . target , 
s_select_info. view, 

X_Windows .Null_Window,  s_select_inf o, 
tae_wpt .WPT_PREFERRED, 

s_select_info .panel^id) ; 

else 
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tae_wpt . Wpt_SetPanelState  ( 
s_seiect_info .panel^id, 
tae_wpt .WPT_PREFERRED) ; 
end  i f ; 

Tae_Wpt .Wpt_Setlntg (s_select_info.panel_id, "s_sele 
ct_item“ .Taeint (0) ) ; 

elsif  s_equal  (valued),  “abandon  step*)  then 
SELECTOR  :=  12; 

if  s_select_info.panel_id  =  NULL_PANEL_ID  then 
tae_wpt .Wpt_NewPanel  s_select_info . target , 

s_select_info . view, 

X_Windows .Null_Window,  s_select_info, 
tae_wpt .WPT_PREFERRED, 

s_select_info.panel_id) ; 

else 

tae_wpt . Wpt_SecPanelState  ( 
s_select_info.panel_ici, 
tae_wpt .WPT_PREFERRED) ; 
end  if; 

Tae_Wpt . Wpt_SetIntg (s_select_inf o .panel_id, " s^sele 
ct_item“ , Taeint (0) ) ; 

elsif  s_equal  (valued),  “quit")  then  null; 
end  i f ; 

tae_wpt .Wpt_PanelReset (main_info .panel_id) ; 
end  inain_selection_l  ; 

procedure  editstep_base_version  (info  :  in 
tae_wpt .event_context_ptr)  is 
value  :  array  d..l)  of  string 

(1. . tae_taeconf . STRINGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  (“Panel  editstep,  parm  base_version:  value 
=  "); 

tae_viii. Vni_Extract_Count  ( info .pann_ptr ,  count); 
if  count  <=  0  then 

text_io . put_l ine  ( " none " ) ; 
else 

tae_vTO. Vm_Extract_SVAL  (info.pann_ptr ,  1,  valued)); 
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text_io.put_line  (valued)); 
end  if; 

base_version(l . .64)  :=  value (1 )( 1 .. 64 ) ; 
end  editstep_base_version; 

procedure  editstep_pri_input  (info  :  in 
tae_wpt . event_contexc_ptr)  is 
value  :  array  (1..1)  of  string 

(1. .tae^taeconf .STRINGSI2E) ; 
count  :  taeint; 

begin 

text_io.put  ("Panel  editstep,  parm  pri_input :  value  = 
“ )  ; 

tae_vin.Vm_Extract_Count  ( info .parm_ptr,  count); 
if  count  <=  0  then 

text_io .put_line  (“none*); 
else 

tae_vin. Vm_Extract_SVAL  (info.pann_ptr,  1,  valued)); 

text_io.put_line  (value(l)); 
end  if; 

primary_input d . . 64 )  :=  value d) (1 .. 64 ) ; 
end  editstep_pri_input; 

procedure  editstep_predecGSsors  (info  :  in 
tae_wpt .event_context_ptr)  is 
value  :  array  (1..1)  of  string 

( 1 . . tae.taeconf . STRINGSIZE) ; 
count  :  taeint ; 

begin 

text_io.put  ("Panel  editstep,  parm  predecessors :  value 
=  ■); 

tae^vm. Vm_Extract_Count  ( info .parm_ptr,  count); 
if  count  <=  0  then 

text_io.put_line  ("none"); 
else 

tae_vm. Vm_Extract_SVAL  (info.parm_ptr,  1,  valued)); 

text_io .put_line  (valued)); 
end  i f ; 

--  need  to  turn  the  predecessors  string  into  suitable  numbers 
for  entry 
--  into  the  ddb 

predecessors (1 . .24)  :=  value (1 ) (1 ..24); 
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--  currently  only  ADD  PREDECESSOR  is  supported. 


end  editstep_predecessorc ; 

procedure  edit3tep_piiority  (info  ;  in 
tae_wpt . event_context_ptr)  is 
value  :  array  (1..1)  of  taeint; 
count  :  taeint; 

begin 

text_io.put  ("Panel  editstep,  parm  priority:  value  = 
")  ; 

tae_vm. Vm_Ex tract _Count  {info.parni_ptr,  count); 
if  count  <=  0  then 

text_io .put_line  ("none"); 
else 

tae_vin. Vm_Extract_IVAL  (info,parTT\_ptr,  1,  valued)); 

text^io .put_line  (taeint ‘ image ( value ( 1 ) ) ) ; 
end  if; 

--  assign  priority  :=  valued)  --  note  type  incompatability 
priority  ;=  integer (value ( 1 ))  ; 

end  editstep_priority ; 

procedure  editstep_exp_level  (info  :  in 
tae_wpt . event_context_ptr)  is 
value  :  array  (l.d)  of  string 

(1 . . tae_taeconf . STRINGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  ("Panel  edicstep,  parm  exp_level;  value  = 
")  ; 

tae_vm. Vm_Extract_Count  (info.parm_ptr,  count); 
if  count  <=  0  then 

text_io .put_line  ("none"); 
else 

tae_vm. Vm_Extract_SVAL  (info.parm_ptr,  1,  valued)); 

text_io.put_line  (valued)); 
end  i f ; 

expert ise_level  (1 .  .6)  :=  valued)  (1 6)  ; 
end  editstep_exp_level ; 

procedure  editstep_deadline  (info  :  in 
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tae_wpt .event_context_ptr)  is 
value  :  array  (1..1)  of  string 

( 1 . . tae_taeconf . STRINGSI2E)  ; 
count  :  taeint; 

begin 

text_io.put  (“Panel  editstep,  parm  deadline:  value  = 
“)  ; 

tae_vin. Vm_Extract_Count  ( info.pann_ptr,  count); 
if  count  <=  0  then 

text^io .put_line  ("none"); 
else 

tae_vm. Vm_Extract_SVAL  (info.pann_j3tr,  1,  valued)); 

text.io .put_line  (valued)); 
end  i f ; 

deadline (1 .. 24 )  :=  value (1) (1 .. 24 ) ; 

end  editstep_deadline; 

procedure  edit step_est_durat ion  (info  :  in 
tae_wpt . event_context_ptr)  is 
value  :  array  d..l)  of  taeint; 
count  :  taeint ; 

begin 

text_io.put  ("Panel  editstep,  parm  est_durat ion :  value 
=  •); 

tae_vm. Vm_Extract_Count  (info.parm_ptr,  count); 
if  count  <=  0  then 

text_io .put_line  ("none"); 
else 

tae_vin. Vm_Extract_IVAL  ( info .parm_ptr ,  1,  valued)); 

text_io.put_line  (taeint ' image (value (1) ) ) ; 
end  if; 

assign  estimated_duration  :=  valued)  --  note  type 
incompatability 

est_duration  :=  integer (value (1 )) ; 

end  editstep_est_duration; 

procedure  editstep_sec_input  (info  :  in 
tae_wpt . event_context_ptr)  is 
value  ;  array  d..l)  of  string 

(1. . tae_taeconf .STRINGSIZE) ; 
count  :  taeint; 
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begin 

text_\o.put  (“Panel  editstep,  parm  sec_input  :  value  = 
• )  ; 

tae_vin.  Vm_Extracc_Count  {  info  .parm_ptr ,  count); 
if  count  <=  0  then 

text_io . put_line  (“none"); 
else 

tae_vin.  Vm_Extract_SVAL  (  info  .  parm_ptr ,  1,  valued)  ); 

text_io  .  put_line  (valued)  ); 
end  i f ; 

--  need  to  modify  the  secandary  input  array  to  reflect  what 
is  in  the  TAE  window 
end  editstep_sec_input ; 

procedure  editstep_af fected  (info  :  in 
tae_wpt . event_context_ptr)  is 
value  :  array  (l.d)  of  string 

( 1 , . tae_taeconf . STRINGSI2E) ; 
count  :  taeint ; 

begin 

text_io.put  (“Panel  editstep,  parm  affected:  value  = 
“)  ; 

tae_vin. Vm_Extract_Count  (info.parm_ptr,  count); 
if  count  <=  0  then 

text_io .put_line  (“none*); 
else 

tae_vm. Vm_Extract_SVAL  (info.parm_ptr,  1,  valued)); 
text_io .put_line  (valued)); 

--  need  to  modify  the  effected  module  array  to  reflect  any  new 
info 
end  if; 

end  editstep_af fected; 


procedure  editstep_return  (info  :  in 

tae_wpt . event_context_ptr)  is 

begin 

if  not  (editstep_info.panel_id  =  NULL_PANEL_ID)  then 
tae^wpt .Wpt_PanelErase ( info .panel_id) ;  end  if; 

end  editstep_return; 


procedure  editstep_apply_step  (info  :  in 
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tae_wpt .event_context_ptr)  is 
value  ;  array  {1..1)  of  string 

(1 . .tae_taeconf .STRINGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  (“Panel  editstep,  parm  apply_step:  value 
=  “); 

tae_vm. Vm_Extract_Count  ( inf o . pann_pt r ,  count); 
if  count  <=  0  then 

text_io .put_line  (“none*); 
else 

tae_vm. Vm_Extract_SVAL  (info .parin_ptr ,  1,  valued)  ); 

text_io . put_line  (valued)); 
end  i f ; 

need  to  write  all  step  stuff  to  ddb 

if  editing_or_creating  =  creating  then  --  creating  a  new 
step 

begin 

note  that  the  parsing  of  the  base  version  and  the  primary 
input 

is  VERY  rudimentary.  We  are  currently  expecting  the  user 
to  know 

the  required  input  form:  base_version  var:ver 

primary_input  var:ver 


if  base_version{l . .3)  /=  “  “  then 

if  primary_input ( 1 . . 3 )  /=  “  “  then 

SELECTOR  :=6; 

Name3(1..64)  :=  base_version (1 . . 64 ) ; 
Name4(1..64)  primary_input (1 . . 64 ) ; 

ECSl  ; 

put_line ( “step  creation  complete"); 

else  put_line(“base  version  and  primary  input 
required  for  step  creation."); 
end  i f ; 

else  put_line ( "base  version  and  primary  input  required 
for  step  creation.*); 
end  if; 
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end; 


else  --  editing  a  step 
begin 


Name4 ( 1 . . 3 ) : = “ 0  0 “ ; 
for  i  in  4 .  .  64  loop 
Name4 ( i ) : = '  ' ; 
end  loop; 

Names ( 1 ) : = ‘ 0 ’ ; 
for  i  in  2.. 64  loop 
Names ( i ) : = ‘  ‘ ; 
end  loop; 

Name6(l. .3) :=-0  0‘; 
for  i  in  4 .  .  64  loop 
Name6 ( i ) : = ’  ' ; 

end  loop; 

Name7 ( 1 ) : = ' 0 ' ; 
for  i  in  2  .  .  64  1 oop 
Name? (i) ; = ’  ' ; 

end  loop; 

Names (1. .3) :=‘0  0" ; 
for  i  in  4.. 64  loop 
Names ( i) : = •  ‘ ; 
end  loop; 

Names ( 1 ) : = ’ 0 ' ; 
for  i  in  2 .  . 64  loop 
Names (i) :='  ’ ; 
end  loop; 

NameA ( 1 ) :  =  ' 0  * ; 
for  i  in  2 .  .  64  loop 
NameA ( i ) : = ’  ' ; 
end  loop; 

Names { 1 )  :  =  ‘  0  * ; 
for  i  in  2  .  .  64  loop 
Names ( i ) : = '  ' ; 
end  loop; 

NameC ( 1 ) :  =  ' 0 •  ; 
for  i  in  2..  64  loop 
NameC ( i ) :  =  ‘  '  ; 
end  loop; 

NameD ( 1 ) :  =  *  5  *  ; 
for  i  in  2  .  .  64  loop 
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NameD ( i )  :  =  '  '  ; 

end  loop; 

NameEd.  .4)  :  =  “n0  O'; 
for  1  in  5 . . 64  loop 
NameE ( i ) ; = '  ' ; 
end  loop; 

taeint_io  .  put  (Naiiie3  ,  taeint  ( St  ep_number  )  )  ;  -- 

if  primary_input ( 1 . . 3 ) / = “  “  then 

Name4 { 1 . . 64 )  : =primary_input ( 1 . . 64 ) ;  --  for 

addition 
end  i f ; 

if  priinary_ir.put  ( 1 .  .  3  )  /  =  ■  “  then 

Names ( 1 .. 64 )  : =primary_input ( 1 . . 64 ) ;  --  for 

delet ion 
end  i f ; 

if  secondary_inputs ( 1 )  ( 1 .  .  3 ) /  =  “  '  then 

Name6(1..64)  :=  secondary_inpats ( 1 )  ( 1 .  .  64 ) ;  --  for 

addition 
end  i f ; 

if  secondary_inputs ( 1 ) ( 1 . . 3 ) / = "  '  then 

Name7(1..64)  :=  secondary_input s ( 1 ) ( 1 . . 64 ) ;  --  for 

deletion 
end  i f ; 

if  affected_modules{l)  (1 .  .3) /  =  “  “  then 

Name8(1..64)  ;=  af f ected_modules ( 1 )  ( 1 .  .  64 ) ;  --  for 

addition 
end  i f ; 

if  af f ected_modules ( 1 )  ( 1  .  .  3 ) /=  "  *  then 

Name9(1..64)  :=  af fected_modules ( 1 ) ( 1 . . 64 ) ;  --  for 

deletion 
end  i f ; 

taeint_io, put (NameA, taeint (priority) ) ;  --  priority 

if  predecessors (1 . .3) /=*  '  then 

NaineB(1..3)  :=  predecessors  ( 1 ..  3  )  ; 
end  i f ; 

taeint_io . put (NameC, taeint ( est_durat ion ) ) ; 
if  expertise_level  (1 .  .  3)  =  “low"  tiien  NameD(l)  :=  '0  ; 
end  i f ; 

if  expert ise_level (1 .. 3 )  =  “med"  then  NameD(l)  :=  '1'; 
end  i f ; 

if  expertise_ievel (1 . . 3 )  =  'hig'  then  NameD(l)  :=  '  2  '  ; 
end  if; 

NameE (1.. 24)  :=  deadline ( 1 .. 24 ) ; 

put ("step  number:");  put(Name3);  new_line; 
put ( "priority :") ;  put (NameA) ;  new_line; 
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put  ( "est  imated  duration:");  put(NaineC);  new_line; 

put_line ( "apply  has  been  depressed  while  in  the  edit 
mode " ) ; 

put_.line  ( "calling  ECS."); 

SELECTOR  :=  7; 

ECSl  ; 


put_line ( "ECS  operations  complete*); 
end; 

end  i f ; 

end  editstep_apply_step; 

procedure  editstep_cancel_step  (info  :  in 
tae_wpt . event_context_ptr )  is 

value  :  array  (1..1)  of  string  ( 1 . . tae_taeconf . STRINGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  ("Panel  editstep,  parm  cancel_step :  value  =  "); 
tae_vm. Vm_Extract_Count  (info.parmjptr,  count); 
if  count  <s  0  then 

text_io.put_line  ("none"); 
else 

tae_vm. Vm_Extract_SVAL  ( inf o .parm_ptr ,  1,  valued)); 
text_io.put_line  (valued)); 
end  i f ; 

--  should  probably  retrieve  all  of  the  old  step  information  and 
refresh 

--  the  edit  step  window 

CLEAR^S.  ,P_INFO; 

for  i  in  1 . .MAX_SEC_INPUTS  loop 

TAE_Wpt .Wpt_SetStringConstraints (editstep_inf o . panel_id 
0 

"sec^input",  Taeint (i), 

secondarY_inputs) ; 


TAE_Wpt .Wpt_SetStringConstraints (editstep_info .panel_id 
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affected*,  Taeintd),  affected_modules)  ; 


end  loop; 


Tae_Wpt .Wpt_SetString (editstep_info.panel_id, ■base_vers 
ion* , 


base_version) ; 

Tae_Wpt .Wpt_SetIntg (editstep_info.panel_id, ‘est_duration" , 

Taeint (est_duration) ) ; 

Tae^Wpt .Wpt_SetString(editstep_info.panel_id, "exp_level" , 

expert ise_level ) ; 

Tae_Wpt .Wpt_SetIntg{editstep_info.panel_id. “priority" , 

Taeint (priority) ) ; 

Tae_Wpt .Wpt_SetString (editstep_info .panel_id, "designer* , 

designer) ; 

Tae_Wpt .Wpt_SetString(editstep_info.panel_id, “deadline* , 

deadline) ; 

Tae_Wpt  .Wpt_SetString  (editstep_info .panel_id,  *start_tiir.3* , 

start_tiine)  ; 

Tae_Wpt . Wpt_SetString {editstep_info .panel^id, *f inish_time* , 

finish_time) ; 

Tae_Wpt .Wpt_SetString (editstep_info .panel_id, *pri_input " , 

primary_input ) ; 

Tae_Wpt ,Wpt_SetIntg(editstep_info.panel_id, *step_number" , 

taeint  (step_nuinber)  )  ; 

Tae_Wpt .Wpt_SetString {editstep_info.panel_id, *sub_steps" , 

sub_steps) ; 


Tae_Wpt .Wpt_SetString (editstep_info .panel_id, *predecess 
ors* , 

predecessors) ; 


end  editstep_cancel«step; 

procedure  editteain_name  (info  :  in  tae_wpt . event_context_ptr)  is 
value  :  array  (1..1)  of  string  ( 1 . . tae_taeconf . STRIMGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  (*Panel  editteam,  parm  name:  value  =  *); 
tae_vin. Vm_Extract_Count  ( info .parm_j)tr ,  count); 
if  count  <a  0  then 

text_io.put_line  (*none*); 
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else 

tae_vm. Vm_Extracu_SVAL  (in£o.parm_ptr,  1,  valued)); 
text_io .put_line  (valued)); 
end  if; 

designer  (1.  .24)  :=  valued)  d  .  .24)  ; 
end  editteain_naine; 

procedure  editteam_ex_opt  (info  :  in  tae_wpt . event_context_ptr )  is 
value  :  array  (1..1)  of  string  (1 . . tae_taeconf . STRINGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  ("Panel  editteam,  parm  ex_opt ;  value  =  "); 
tae_vin. Vm_Extract_Count  (info.pann_ptr,  count); 
if  count  <=  0  then 

text_io.put_line  ("none"); 
else 

tae_vm.Vm_Extract_SVAL  ( info .parmjptr ,  1,  valued)); 
text_io . put_line  (value (1 ) ) ; 

Tae_Wpt .Wpt_SetString(editteam_info.panel_id, "expertise" , 

valued) )  ; 

expert i se_l evel (1 . .24)  :=  value (1 ) (1 .. 24 ) ; 
end  if; 

end  editteam_ex_opt ; 

procedure  editteam_d_cancel  (info  :  in  tae_wpt . event_context_ptr) 
is 

value  :  array  d..l)  of  string  d .. tae_taeconf . STRINGSIZE) ; 
count  ;  taeint ; 

begin 

text_io.put  ("Panel  editteam,  parm  d_cancel :  value  =  "); 
tae_vm. Vm_Extract_Count  ( info .parm_ptr ,  count) ; 
if  c  ant  <=  0  then 

text_io.put_line  ("none"); 
else 

tae_vin. Vm_Extract_SVAL  {info.pann_ptr,  1,  valued)  ); 
text_ic  .put_line  (valued)  ); 
end  if; 

if  info.paneI_id  =  NULL_PANEL_1D  then 

tae_wpt .Wpt_NewPanel  {"",  info. target,  info. view, 
X_Windows .Null_Window,  info,  tae_wpt . WPT_PREFERRED, 
info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

info,panel_id,  tae_wpt .WPT_PREFERRED) ; 
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end  if; 

Tae_Wpt .Wpt_SetString (editteam_info.panel_id, “name" , 

•  • )  ; 

Tae_Wpt .Wpt_SetString (editteam_inf o .panel_id, “expertise" , 

“  ‘)  ; 

Tae_Wpt .Wpt_SetString (editteam_info .panel_id, “status" , 

•  ■■)  ; 
end  editteam_d_canceJ.  ; 

procedure  editteam_designers  (info  :  in  tae_wpt .  event_context_ptr) 
is 

value  :  array  (1..1)  of  string  ( 1 . . tae_taeconf . STRINGSIZE) ; 
counv  :  taeint; 

begin 

text_io.put  (“Panel  editteam,  parm  designers:  value  =  "); 
tae_vn[i. Vm_Extract_Count  (info.parin_ptr,  count); 
if  count  <s  0  then 

text_io.put_line  ( “none" ) ; 
else 

tae_vm. Vm_Extract_SVAL  (info.pann_ptr,  1,  valued)); 
text^io .put^line  (valued)); 
end  if; 

Tae_Wpt  .Wpt_Set String  (edittean\_info.panel_id,  “name" , 

valued)  (1.  .24)  )  ; 

designer (1 .  .24)  ;=  valued)  (1.  .24) ; 

Tae_Wpt .Wpt^SetString(editteam_info.panel_.id, “expertise* , 

valued)  (25.  .30)  )  ; 
expertise_level (1 . . 6 )  :=  value (1) (25 . . 30) ; 

Tae_Wpt .Wpt_SetString (editteam_info.panel_id, “status “ , 

valued)  (44.  .51)  )  ; 
designer_status  (1 .  .4)  :=  valued)  (44  .  .47)  ; 

end  editteam_designers; 

procedure  editteam_selection_3  (info  :  in 
tae_wpt .event_context_ptr)  is 

value  :  array  (1..1)  of  string  (1 .. tae_taeconf . STRINGSIZE) ; 
count  :  taeint ; 

begin 

text_io.put  ("Panel  editteam,  parm  selection_3:  value  =  “); 
tae_vtn. Vm_Extract_Count  (info,parm_ptr,  count); 
if  count  <=  0  then 

text_io.put_line  (“none“); 
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else 

tae_vin. Vm_Extract_SVAL  { info . parm_ptr,  1,  value(l)); 
text_io.put_li.. 2  (valued)); 
end  if; 

if  (FALSE)  then  null; 

elsif  s_equal  (valued),  "add  designer")  then 
--  add  designer  to  ddb 


Name3(1..24)  :=  designer (1 .. 24 ) ; 

if  expert i se_l evel d . 
end  i f ; 

.3)  =  "low" 

then 

Name4 ( 1 ) 

:  =  •  0  *  ; 

if  expert ise_level (1 . 
end  i f ; 

. 3 )  =  " med " 

then 

Name4 ( 1 ) 

:=  •!•; 

if  expertise_level d . 
end  if; 

.3)  =  "hig" 

then 

Name4 ( 1 ) 

:=  d-; 

put_line ( "calling  ECS"); 

SELECTOR  :=  14; 

ECSl  ; 

tae_wpt .Wpt_PanelReset (editteain_info.panel_id) ; 

--  now  read  the  new  transfer  file  and  update  the  TAB  item 

SELECTOR  :=  13;  --  remove  transfer  file 

ECSl  ; 

SELECTOR  :=  15;  --  write  designer  list  to  transfer  file 

ECSl  ; 

put_line( "designer  addition  complete"); 

--  read  in  the  designers  from  the  transfer  file  (ddbdisplay)  into 
the  editteaun  panel 

text_io.OPEN(data_f ile,  text_io . IN_FILE, "ddbdisplay") ; 
counter  :=  1 ; 

while  not  end_of_f ile (data_f ile)  loop 


get_line(data_file,designer_info(counter) .all, length) ; 

TAE_Wpt .Wpt_SetStringConstraints (editteam_info .panel_id 
$ 

"designers",  Taeint (counter) ,  designer_info) ; 
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counter  :=  counter  +  1; 
end  loop; 

text_io. CLOSE (data^file) ; 
for  i  in  counter . .MAX_DESIGNERS  loop 
designer_info(i) .all  := 

m  "  • 

i 

TAE_Wpt .Wpt_SetStringConstraints (editteam_info .panel_id 
“designers*,  Taeint (counter ) ,  designer_info) ; 

end  loop; 


elsif  s_equal  (valued),  “delete  designer*)  tlien 
Name3(1..24)  :=  designer(1..24); 

Name4(1..4)  :=  designer^status (1 . . 4) ; 

if  conf inn_info.panel_id  =  NULL_PANEL_ID  then 

tae_wpt  .Wpt_NewPanel  (““,  confiirm^inf  o .  target , 
conf inn_info . view, 

X_Windows .Null_Window,  conf inn_info, 
tae_wpt .WPT_PREFERRED, 

confirTn_info.panel_id)  ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

conf inn_info.panel_id,  tae_wpt .WPT_PREFERRED) ; 

end  if; 

elsif  s_equal  (valued),  “change  expertise  level*)  then 
--  update  designer  info  in  ddb 
begin 

NAME3(1..24)  :=  designer ( 1 .. 24 ) ; 

if  expert i se_l evel  d  .. 3 )  =  “low*  then  Name4d)  :  = 
'O';  end  if ; 

if  expert ise_level  d ..  3)  =  “med*  then  Namfe4d)  :  = 

' 1 ' ;  end  i f ; 

if  expertise_level  (1 .  .3)  =  “hig*  then  Name4d)  :  = 

' 2 ' ;  end  i f ; 
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put_line { "calling  ECS'); 

SELECTOR  :=  17; 

ECSl  ; 

tae_wpt .Wpt_PanelReset (editteain_info.panel_id) ; 

--  now  read  the  new  transfer  file  and  update  the  TAE  item 

SELECTOR  :=  13;  --  remove  transfer  file 

ECSl; 

SELECTOR  ;=  15;  --  write  designer  list  to  transfer  file 

ECSl  ; 

put_line ( “designer  expertise  modification  complete'); 

--  read  in  the  designers  from  the  transfer  file  (ddbdisplay)  into 
the  editteam  panel 

text_io.OPEN(data„file,  text^io. IN_FILE, 'ddbdisplay') ; 
counter  :=  1; 

while  not  end_of_file(data_f ile)  loop 

get_line(data_file,designer_info (counter) .all, length) ; 

TAE_Wpt . Wpt_SetStringConstraints {editteam_info.panel_id 
$ 

"designers',  Taeint (counter) ,  designer_info) ; 
counter  ; =  counter  +  1 ; 

end  loop; 

text_io, CLOSE (data_file)  ; 
for  i  in  counter. .MAX_DESIGNERS  loop 
designer_info(i) .all  := 

**  M  . 

/ 

TAE_Wpt .Wpt_SetStringConstraints (editteam_info.panel_id 
'designers',  Taeint (counter) ,  designer_info) ; 
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end  loop; 
end; 

elsif  s_equal  (valued),  "return  to  main  menu")  then 

tae_wpt .Wpt^PanelReset (editteam_info.panel_id) ; 

if  not  (editteam_inf o .panel_id  =  NULL_PANEL_ID)  then 
tae_wpt .Wpt_PanelErase(info.panel_id) ;  end  if; 

end  if; 

end  editteam_selection_3 ; 

procedure  confirm_yes  (info  :  in  tae_wpt .event_context_ptr)  is 
value  :  array  (1..1)  of  string  ( 1 . . tae_taeconf . STRINGSIZE) ; 
count  :  taeint; 

begin 

text_io.put  ("Panel  confirm,  parmyes:  value  *  "); 
tae^vm. Vm_Extract_Count  (info.parm_ptr,  count); 
if  count  <=  0  then 

text_io.put_line  ("none"); 
else 

tae_VTn.Vm_Extract_SVAL  dnfo .parm_ptr,  1,  valued)); 
text_io.put_line  (valued)); 
end  if; 

tae_wpt .Wpt_PanelErase(info.panel_id) ; 

--  remove  designer  from  ddb 

put_line ( "calling  ECS"); 

SELECTOR  :=  16; 

ECSl  ; 


tae_wpt .Wpt_PanelReset (editteam_info .panel_id) ; 

--  clear  the  TAE  panel  items 

Tae_Wpt .Wpt_SetString(editteain_info.panel_id, "name" , 

■  •)  ; 

Tae_Wpt .Wpt_SetString(editteam_info.panel_id, "expertise" , 

'  •); 

Tae_Wpt .Wpt_Set String ( editteam_inf o . panel_id, “ status " , 

"  " )  ; 
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--  read  the  new  designer  list  from  the  transfer  file 

SELECTOR  :=  13; 

ECSl; 

SELECTOR  :=  15; 

ECSl; 

put_line { “designer  deletion  complete*); 

--  read  in  the  designers  from  the  transfer  file  (ddbdisplay)  into 
the  editteam  panel 

text_io.OPEN(data_file,  text_io . IN_FILE, “ddbdisplay") ; 
counter  :=  1; 

while  not  end_of_f ile (data_f ile)  loop 

get_line(data_file,designer_info(counter) .all, length) ; 
TAE_Wpt . Wpt_SetStringConstraints (edi tteam^info. panel_id 

i 

“designers",  Taeint (counter) ,  designer_info) ; 
counter  counter  +  1; 

end  loop; 

text_io .CLOSE (data_file) ; 
for  i  in  counter . .MAX_DESIGNERS  loop 
designer_info (i) .all  := 

m  •»  . 

t 

TAE_Wpt .Wpt_SetStringConstraints (editteam_info .panel_id 
$ 

“designers",  Taeint (counter) ,  designer_info) ; 
end  loop; 
end  confirm_^es; 

procedure  confirm_no  (info  :  in  tae^wpt . event_context_ptr)  is 
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begin 


put_line ( "cancelling  designer  deletion"); 

--  do  nothing 

tae_wpt .Wpt_PanelErase(info.panel_id) ; 
end  confinn_no; 

procedure  s_select_s_select_itein  (info  :  in 
tae_wpt . event_context_ptr )  is 
value  :  array  (1..1)  of  taeint; 
count  :  taeint ; 

begin 

text_io.put  ("Panel  s_select.  parm  s_select_item:  value 
")  ; 

tae_vm.Vm_Extract_Count  ( info .parm_ptr,  count); 
if  count  <=  0  then 

text_io.put_line  ("none"); 
else 

tae_vin. Vm_Extract_IVAL  (info.parTn_ptr,  1,  valued)  ) 
text_io .put_line  (taeint ‘ image (value (1 ) ) ) ; 
taeint_io .put  (Name3,  (valued) )  )  ; 

end  if; 

put_line ( "calling  ECS"); 

ECSl  ; 

put_lin9( "ECS  operation  complete*); 

tae_wpt .Wpt_PanelErase(info.panel_id) ; 
end  s_select_s_select_item; 

procedure  showstep_s_select_item  (info  :  in 
tae_wpt . event_context_ptr)  is 
value  :  array  (1..1)  of  taeint; 
count  :  taeint ; 

begin 

text_io.put  ("Panel  showstep,  parm  s_select_item:  value 

")  ; 

tae_vm.Vm_Extract_Count  (info.parm_ptr,  count); 
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if  count  <=  0  then 

text_io .put_line  (“none*); 
else 

tae_vin.Vm_Extract_lVAL  ( inf  o  .  parm_ptr ,  1,  valued)  ); 
text_io .put_line  (taeint ' image (value ( 1 ) ) )  ; 
end  if; 

taeint_io .put  (Name3,  (valued) ) )  ; 
step_nuinber  :=  integer  (value  ( 1 ))  ; 

SELECTOR  :=  3; 

ECSl;  --  this  creates  a  file  called  ‘ddfadisplay’  and  puts  all  the 
step 

--  info  in  the  file 
CLEAR_STEP_INFO ; 

now  create  the  new  window 

tae_wpt .Wpt_PanelErase (showstep_info .panel_id) ; 
if  show_info .panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  show_info. target, 

show_info.view, 

X_Windows .Null_Window,  show^info, 
tae_wpt .WPT_ PREFERRED, 

show_info.panel_id) ; 

else 

tae_wpt .Wpt^SetPanelState  ( 

show_info .panel_id,  tae_wpt .WPT_PREFERRED) ; 

end  if; 

--  make  sure  that  the  panel  items  are  cleared 

for  i  in  1 . .MAX_SEC_INPUTS  loop 

TAE^Wpt .Wpt_SetStringConstraints (show_info.panel_id, 

*sec_input“,  Taeint (i), 

secondary_inputs) ; 


TAE_Wpt . Wpt_SetStringConstraints {show_inf o. panel_id, 

“affected",  Taelnt(i),  affected_modules) ; 

end  loop; 

Tae_Wpt .Wpt_SetString(show_info.panel_id, "base_version" , 

base_version) ; 

Tae_Wpt .Wpt_SetIntg (show_info .panel_id, “est_duration“ , 

Taeint (est_duration) ) ; 
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Tae_Wpt .Wpt_SetString (show_info .panel_id, ‘exp_level “ , 

expertise_level ) ; 

Tae_Wpt  .Wpt_S'?tIntg  (show_info.panel_id,  "priority" , 

Taeint (priority) ) ; 

Tae_Wpt .Wpt_SetString(show_info.panel_id, "designer" , 

designer) ; 

Tae_Wpt .Wpt_SetString(show_info.panel_id, "deadline" , 

deadline) ; 

Tae_Wpt .Wpt^SetString (show_info.panel_id, "start_time" , 

start_time) ; 

Tae_Wpt .Wpt_SetString (show_info .panel_id, " f inish_time“ , 

f inish_time) ; 

Tae_Wpt .Wpt_SetString (show_info.panel_id, "pri_input " , 

primary_input ) ; 

Tae_Wpt . Wpt_SetIntg (show_info .panel_id, "step_number* , 

taeint (step_n umber) ) ; 

Tae_Wpt .Wpt_SetString (show_info.p«nel_id, "sub_steps" , 

sub_steps) ; 

Tae^Wpt .Wpt_SetString (show_info.panel_id, "predecessors" . 

predecessors) ; 

--  read  from  file  created  by  ECSl  into  TAE  variables 

--  for  display  in  'show*  panel. 

text_io.put_line{ "opening  file") ; 

text_io.OPEN(data_f ile, 
text_io . IN_FILE, "ddbdisplay " ) ; 

text_io.put_line( "reading  from  file"); 

t ext_io . get_l ine ( data_f i le , base_vers ion , length ) 
for  i  in  length+1..64  loop 
base_version ( i ) : * ’  ' ; 
end  loop; 

get (data_f ile, est_duration) ; 
skip_line (data_f ile)  ; 
get (data_f ile, priority)  ; 
s)«ip_line (data_f ile)  ; 

text_io.get_line(data_file, expertise_level , length) ; 
for  i  in  length+1..24  loop 
expertise^level ( i ) : = '  ' ; 
end  loop; 

text_io.get_line(data_file, status, length) ; 
for  i  in  length+1..24  loop 
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status ( 1 ) : = ‘  ’ ; 

end  loop; 

text_io.get_line(data_f lie, designer, length) ; 
for  i  in  length+1..24  loop 
designer ( i ) :  =  '  '  ; 

end  loop; 

text_io.get_line(data_f lie, deadline, length) ; 
for  i  in  length-t-1 .  . 24  loop 
deadline ( i ) : = '  ' ; 

end  loop; 

text_io.get_line(data_file, start_time, length) ; 
for  i  in  length+1..24  loop 
start_tinie  ( i )  :  =  ‘  ‘; 
end  loop; 

text_io.get_line(data_f ile, finish_time, length) ; 
for  i  in  length+1..24  loop 
f inish_time ( i ) : = ■  '; 

end  loop; 

text_io .get_line(data_f ile, primary_input , length) ; 
for  i  in  length+1..64  loop 
priinary_input  (i)  :  =  '  '  ; 
end  loop; 

read  number  of  secondary  inputs  followed  by  secondary  inputs 

get  (data_f  ile,  counter)  ;  s)tip_line  (dat3_f  ile)  ; 
if  counter  >  0  then 
for  i  in  1.. counter  loop 

text_io.get_line(data_file, secondary_inputs (i) .all, leng 
th)  ; 

for  j  in  length+1..64  loop 
secondary_inputs ( i ) ( j ) ; = ’  ' ; 
end  loop; 

TAE_Wpt .Wpt_SetStringConstraints ( show_info .panel_id, 

*sec_input",  Taelnt(i), 

secondary_inputs ) ; 

end  loop; 
end  if; 

now  read  number  of  affected  modules  followed  by  affectecd 
modules 

get  (data_f  ile,  counter)  ;  sl<ip_line  (data_f  ile)  ; 
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if  counter  >  0  then 
for  1  in  1.. counter  loop 

text_io . get_line (data_f ile<  af  f ected_modules ( i )  .all, leng 
th)  ; 

for  j  in  length+1..64  loop 
af fected_modules ( 1 )(]);= ■  ' ; 

end  loop; 

TAE_Wpt . Wpt_SetStringConstraints {show_: nfo . panel_id, 

•affected*.  Taelnt(i),  af f ected_modules ) ; 
end  loop; 
end  i f ; 

get (data_f ile, counter) ; 

if  counter  >  0  then  skip_line (data_f ile) ; 

get_line (data_f ile, sub_steps, length) ; 

else  s)cip_line  (data_f  ile)  ; 

end  i f ; 

get (data_f ile, counter )  ; 

if  counter  >  0  then  sl<ip_line(data_f ile)  ; 

get_line (daca_f ile, predecessors, length) ; 
end  i f ; 

text_io .put_line { “done  reading,  writing  to  panel*); 
text_io .put_line ( "done  writing  to  panel,  closing  file*); 

text_io. CLOSE (data_f ile) ; 

--  now  write  all  the  new  step  information  into  the  TAE  window 

Tae_Wpt .Wpt_SetString {show_info .panel_id, "base_version  * , 

base_version) ; 

Tae_Wpt ,Wpt_SetIntg (show_info .panel_id, *est_duration" , 

Taeint (est_duration) ) ; 

Tae_Wpt .Wpt_SetString (show_info .panel_id, “exp_level * , 

expert ise_level ) ; 

Tae_Wpt .Wpt_SetIntg {show_info.panel_id, “priority* , 

Taeint (priority) ) ; 

Tae_Wpt .Wpt_SetString (show_info.panel_id, "designer* , 

designer) ; 

Tae_Wpt .Wpt_SetString (show^info .panel_id, "deadline* , 
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deadline) ; 

Tae_Wpt . Wpt_SetString (show_info .panel_id, *start_time“ , 

start_time) ; 

Tae_Wpt .Wpt_SetString(show_info.panel_id, ■finish_tiine‘ , 

f  inish_cirr\e)  ; 

Tae_Wpt .Wpt_SetString(show_infr .panel_id, “pri_input  * , 

primary_input ) ; 

Tae_Wpt .Wpt_SetIntg (show_info,panel_id, * step.number* , 

value (1) ) ; 

Tae_Wpt .Wpt_SetString(show_info.panel_id, “sub^steps" , 

sub_steps) ; 

Tae_Wpt .Wpt_SetString {show_info .panel_id, “predecessors* , 

predecessors) ; 


exception 

when  text_io.NAME_ERROR  => 

text_io.put_line( “ERROR:  non-existent  transfer  file 
(probably  * ddbdisplay 
when  text_io.END_ERROR  => 

text_io.put_line( “ERROR:  corrupt  transfer  file 
(probably  ‘ddbdisplay 

if  is_open {data_file)  then  close(data_file) ;  end  if; 
when  text_io . STATUS_ERROR  => 

if  i3_open (data_f ile)  then  close (data_file) ;  end  if; 


end  showstep_s_select_item; 

procedure  show_step_number  (info  :  in  tae_wpt .event_context_ptr) 
is 

begin 

null; 

end  show_step_nuinber; 

procedure  show_show_f inish  (info  :  in  tae_wpt .event_context_ptr) 
is 

value  :  array  (1..1)  of  string  ( 1 . . tae_taeconf . STRINGSIZE) ; 
count  :  taeint ; 

begin 

text_io.put  (“Panel  show,  parm  show_f inish:  value  =  "); 
tae_vm. Vni_Extract_Count  (info.pannjptr,  count)  ; 
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if  count  <=  0  then 

text_io .put^line  (“none"); 
else 

tae_VTn. Vin_Extract_SVAL  ( info .pann_ptr ,  1,  valued)  )  ; 
text_io.put_line  (valued)); 
end  if; 

tae_wpt .Wpt_PanelErase(info.panel_id) ; 
end  show_show_f inish; 

procedure  textl_display_done  (info  :  in  tae_wpt .event_context_ptr) 
is 

begin 

SELECTOR  :=  13;  --  this  selection  erases  the  transfer  file 

--  (currently  'ddbdisplay ' )  for  its  next  use 

ECSl  ; 

tae_wpt .Wpt_PanelErase(info.panel_id) ; 
end  textl_display_done; 

procedure  textl_text_itein_l  (info  :  in  tae_wpt . event_context_ptr ) 
is 

begin 

null; 

end  textl_text_itexn_l ; 

procedure  steptype_type_selection  (info  :  in 
tae_wpt . event_context_ptr )  is 

value  :  array  (1..1)  of  string  (1 . . tae_taeconf . STRINGSIZE) ; 
count  :  taeint; 

begin 
SELECTOR  :=  2; 

text_io.put  ("Panel  steptype,  parm  type_selection :  value  = 

tae_vin. Vm_Extract_Count  (info.pann_ptr,  count); 
if  count  <=  0  then 

text_io.put_line  ( "none" ) ; 
else 

tae_vin.Vin_Extract_SVAL  ( info .parn\_ptr ,  1,  valued)); 


text_io .put_line  (valued)); 
end  if; 

if  (FALSE)  then  null; 
elsif  s_equal  (valued),  *all“)  then 
Name3(1..3)  :=  “all‘; 

for  i  in  4 . . 64  loop 
Naine3  ( i )  ;  =  '  ’ ; 
end  loop; 

ECSl; 

if  info .panel_id  =  NULL_PANEL_ID  then 

tae^wpt  .Wpt_NewPanel  ( ■•  “ ,  info,  target,  info,  view, 
X_Windows .Null_Window,  info,  tae_wpt . WPT_INVISIBLE, 
info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

info.panel_id,  tae_wpt .WPT^INVISIBLE) ; 

end  if; 

if  textl_info .panel_id  =  NULL_PANEL_ID  then 

tae_wpt ,Wpt_NewPanel  C*",  textl_info. target, 
text l^info .view, 

X_Windows .Null^Window,  textl.inf o, 
tae_wpt .WPT^PREFERRED, 

textl_info.panel_id) ; 

else 

tae^wpt .Wpt_SetPanelState  ( 

textl^info.panel^id,  tae^wpt .WPT_PREFERRED) ; 

end  if; 

elsif  s_equai  (valued),  "top")  then 
Name3 (1 . . 3 )  : =  “ top " ; 

for  i  in  4.. 64  loop 
Name3 ( i ) ; = '  • ; 
end  loop; 

ECSl  ; 

if  info.panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  ("",  info. target,  info. view, 
X_Windows .Null^Window,  info,  tae_wpt .WPT^INVISIBLE, 
info.panel_id> ; 

else 

tae_wpt . Wpt_SetPanelState  ( 

info.panel_id,  tae_wpt .WPT_INVISIBLE) ; 

end  if; 

if  textl_info.panel_id  »  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  (*’,  textl^info . target , 
text l_inf o .view, 

X_Windows .Null_Window,  textl^info, 
tae_wpt .WPT_PREFERRED, 
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textl_info .panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

textl_info.panel_id,  tae_wpt . WPT_PREFERRED) ; 

end  i f ; 

elsif  s_equal  (valued),  ‘proposed")  then 
Naine3(1..8)  :=  "proposed"; 

for  i  in  9 .  .  64  loop 
Name3 ( i ) : = ‘  ' ; 
end  loop; 

ECSl  ; 

if  info .panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  (*",  info. target,  info. view, 
X_Windows .Null_Window,  info,  tae^wpt .WPT_INVISTBLE, 
info.panel^id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

info  .panel^id,  tae_wpt  .WPT_IWISIBLL,  ; 

end  if; 

if  textl_info.panel_id  =  NULL_PANEL_ID  then 

cae_wpt .Wpt_KewPanel  textl_info. target, 

textl_info.view, 

X_Windows .Null_Window,  textl_info, 
tae_wpt .WPT.PREFERRED, 

textl_info.panel_id) ; 

else 

tae_wpt .Wpt^SetPanelState  ( 

textl_info.panel_id,  tae_wpt .WPT^PREFERRED) ; 

end  if; 

elsif  s_equal  (valued),  "approved")  then 
Naine3  (1 .  .  8 )  ; »  *  approved  "  ; 

for  i  in  9 . . 64  loop 
Names ( i ) : = •  ' ; 
end  loop; 

ECSl  ; 

if  info.panel_id  «  NULL^PANEL.ID  then 

tae_wpt .Wpt_NewPanel  ("",  info. target,  info. view, 
X_Windows .Null_Window,  info,  tae_wpt .WPT_INVISIBLE, 
info.panel_id) ; 

else 

tae^wpt .Wpt_SetPanelState  { 

info.panel^id,  tae_wpt .WPT_INVISIBLE) ; 

end  if; 

if  textl_info.panel_id  =  NULL_PANEL_ID  then 

tae_wpt . Wpt_NewPanel  ("",  textl_info. target, 
textl_info . view. 
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X_Windows .Null_Window,  textl_info, 
tae_wpt .WPT^PREFERRED, 

textl_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  I 

textl^inf o  .panel_id,  tae_vynpt  .WPT_PREFERRED)  ; 

end  if; 

elsif  s_equal  (valued),  -scheduled*)  then 

Names (1.. 9)  :=  “scheduled*; 

for  i  in  10.. 64  loop 
Names { i ) : = ‘  ' ; 
end  loop; 

ECSl  ; 

if  info.panel_id  =  NULL_PANEL_ID  then 

tae_wpt.Wpt_NewPanel  (*'.  info. target,  info. view, 
XJWindows .Null.Window,  info,  tae_wpt . WPT_INVISIBLE, 
info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  { 

info.panel_id,  tae_wpt .WPT_INVISIBLE) ; 

end  if; 

if  textl_info.panel„id  *  NULL_PANEL_ID  then 

tae_^t.Wpt_NewPanel  (**,  textl^info. target , 
textl.info.view, 

X_Windows .Null_Window,  textl_inf o, 
tae_wpt .WPT.PREFERRED, 

textl_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

textl_info.panel_id,  tae_wpt .WPT_PREFERRED) ; 

end  if; 

elsif  s^equal  (valued),  “assigned*)  then 

Names (1.. 8)  :=  “assigned*; 

for  i  in  9 . . 64  loop 
Names (i):»' 
end  loop, 

BCSl  • 

if  inf o .panel_id  =  NULL_PANEL_ID  then 

tae_wpt.Wpt_NewPanel  (**,  info. target,  info. view 
X_Windows .Null_Window,  info,  tae_wpt .WPT_INVISIBLE 
info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

info .panel_id,  tae_wpt .WPT_INVISIBLE) ; 

end  if; 

if  textl_inf o . panel_id  =  NULL_PANEL_ID  then 
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tae.wpt .Wpt_NewPanel  C",  textl_info. target, 
t ext l_info. view, 

X_Windows .Null_Window,  textl_info, 
tae^wpt .WPT_PREFERRED, 

textl_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

textl_info.panel_id,  tae_wpt .WPT_ PREFERRED) ; 

end  if; 

elsif  s_equal  (valued),  “completed")  then 
Name3{1..9)  :*  “completed"; 

for  i  in  10.. 64  loop 
Name3 ( i ) : = '  ‘ ; 
end  loop; 

ECSl; 

if  info .panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  (““,  inf c. target,  info. view, 
X_Windows .Null^Window,  info,  tae_wpt .WPT_INVISIBLE, 
info. pane l^id) ; 

else 

tae^wpt .Wpt_SetPanelState  ( 

info.panel_id,  tae^wpt .WPT^INVISIBLE) ; 

end  if; 

if  textl_info.panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  (““,  textl_info. target, 
texi  l_info.view, 

X_Windows .Null^Window,  textl^info, 
tae_wpt .WPT_PREFERRED, 

textl_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

textl_info.panel_id,  tae_wpt . WPT_PREFERRED) ; 

end  if; 

elsif  s_equal  (valued),  “abandoned’)  then 
Name3 (1 . . 9 )  : «  “ abandoned* ; 

for  i  in  10.. 64  loop 
Name3 { i ) : = ’  ' ; 
end  loop; 

ECSl; 

if  info .panel_id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  {““,  info. target,  info. view, 
X_Windows .Null_Window,  info,  tae_wpt .WPT_INVISIBLE, 
info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

info .panel_id,  tae_wpt .WPT_INVISIBLE) ; 
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end  if; 

if  textl_info.panel^id  =  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  (  “■ ,  text l_info . target , 
textl_info . view, 

X_Windows .Null_Window,  textl_info, 
tae_wpt .WPT_PREFERRED. 

textl_info .panel_id)  ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

textl_info .panel_id,  tae^wpt .WPT_PREFERRED) ; 

end  if; 
end  if; 

end  steptype_type_selection; 

procedure  editnuin_s_select_itein  (info  :  in 
tae_wpt . event_context_ptr)  is 
value  :  array  (1..1)  of  taeint; 
count  :  taeint ; 

begin 

text_io.put  (“Panel  editnum,  paim  s_select^item:  value  =  “) 
tae_vtn.Vin_Extract_Count  (info.parmjptr,  count)  ; 
if  count  <=  0  then 

text_io.put_line  (“none"); 
else 

tae^vin.Vm_Extract_IVAL  ( info .pann_jptr ,  1,  valued)); 
text_io .put_line  (taeint *  image (value (1) ) ) ; 
end  if; 

tae_wpt .Wpt_PanelErase (info.panel_id) ; 

--  write  step  info  to  transfer  file 

taeint_io.put  (Name!  ,  (valued) ) )  ; 
step_number  :=  integer  (valued) )  ; 

SELECTOR  :=  3; 

ECSl  ; 

editing_or_creating  :=  editing; 

CLEAR_STEP_INFO; 

--  create  new  panel 

if  editstep_info.panel^id  *  NULL_PANEL_ID  then 

tae_wpt .Wpt_NewPanel  ("“,  editstep_info . target , 
editstep_info. view, 

X_Windows .Null_Window,  editstep_info, 
tae_wpt .WPT_PREFERRED, 
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editstep_info.panel_id) ; 

else 

tae_wpt .Wpt_SetPanelState  ( 

editstep_irifo  .panel_id,  tae_wpt  .WPT_PREFLRRED)  ; 

end  if; 

make  sure  that  the  panel  items  are  cleared 

for  i  in  1 . .MAX_SEC_INPUTS  loop 

TAE_Wpt .Wpt_SetStringConstraints (editstep_info .panel_id 
$ 

*sec_input‘,  Taelnt(i), 

secondarY_inputs) ; 


TAE_Wpt .Wpt_SetStringConstraints {editstep_info.panel_id 

i 

"affected*.  Taelnt(i),  affected_modules) ; 
end  loop; 


Tae_Wpt .Wpt_SetString(editstep_info.panel_id, *base_vers 
ion" , 


base_version) ; 

Tae_Wpt .Wpt_Setlntg (editstep^info.panel_id, "est^duration* , 

Taeint (est^duration) ) ; 

Tae^Wpt .Wpt_SetString(editstep_info.panel_id, *exp_level" , 

expert ise_level ) ; 

Tae^Wpt ,Wpt_SetIntg (editstep_info.panel_id, "priority" , 

Taeint (priority) ) ; 

Tae_Wpt .Wpt_SetString (editstep_info.panel_id, "designer" , 

designer) ; 

Tae_Wpt .Wpt_SetString(editstep_info.panel_id, "deadline" , 

deadline) ; 

Tae_Wpt .Wpt_SetString(editstep_info.panel_id, *start_time* , 

start_time) ; 

Tae_Wpt .Wpt_SetString{editstep_info.panel_id, " f inish_time" , 

finish_time) ; 

Tae_Wpt .Wpt_SetString(editstep_info.panel_id, "pri_input" , 

primary_input) ; 

Tae_Wpt .Wpt_SetIntg (editstep_info.panel_id. "step_number“ , 

taeint {step_number) ) ; 

Tae^Wpt .Wpt_SetString(editstep_info.panel_id, "sub_steps" , 

sub_steps) ; 


404 


Tae_Wpt .Wpt_SetString (editstep_info .panel_id, "predecess 
ors" , 

predecessors) ; 


--  now  read  the  file 

text_io.put_line ( “opening  file* )  ; 

text_io.OPEN(data_f ile, 
text_io. 1N_FILE, “ddfadisplay" ) ; 

text_io .put^line ( “reading  from  file*); 

text_io.get_iine(data_file, base_version, length) ; 
for  i  in  length+1..64  loop 
base_version ( i ) : = '  ‘ ; 

end  loop; 

get (data_file,est_duration) ; 
skip_line(data_f ile) ; 
get (data_file, priority) ; 
skip_line(data_file) ; 

text_io. get_line (data^f ile, expert ise^level , length) ; 
for  i  in  length+l. .24  loop 
expertise_level ( i ) : = ’  ' ; 
end  loop; 

text_io .get_line (data_f ile, status , length) ; 
for  i  in  length+1..24  loop 
statusd)  :  =  *  •  ; 
end  loop; 

text_io.get_line (data_f ile, designer, length) ; 
for  i  in  length+1..24  loop 
designer ( i) ’; 
end  loop; 

text_io.get_line(data_f ile, deadline, length) ; 
for  i  in  length+1..24  loop 
deadline (i) ;='  ’ ; 
end  loop; 

text_io.get_line(data_f ile, start_time, length) ; 
for  i  in  length+1..24  loop 
start_time(i) :='  ’; 
end  loop; 

text_io.get_line(data_f ile, finish_time, length) ; 
for  i  in  length+1..24  loop 
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f inish_time ( i ) : = ‘ 
end  loop; 

text_io .get_line (data_f ile, primary_i nput , length) ; 
for  i  in  length+1 . . 64  loop 
primary_input ( i) : = * 
end  loop; 

read  number  of  secondary  inputs  followed  by  secondary  inputs 

get (data_f ile, counter) ;  skip_line (data_f ile) ; 
if  counter  >  0  then 
for  i  in  1.. counter  loop 

text_io.get_line(data_file, secondary_inputs (i) .all, leng 
th)  ; 

for  j  in  length+1..64  loop 
secondary_inputs (i) ( j ) := '  ' ; 
end  loop; 

TAE_Wpt .Wpt_SetStringConstraints (editstep_info,panel_id 
« 

• sec_input  * ,  Taeint { i ) , 

secondary_inputs) ; 

end  loop; 
end  if; 

now  read  number  of  affected  modules  followed  by  affectecd 
modules 


get (data_f ile, counter) ;  skip_line (data_f ile) ; 
if  counter  >  0  then 
for  i  in  1.. counter  loop 

text_io . get_line (data_f ile, af  f ected_modules ( i ) . all , leng 
th)  ; 

for  j  in  length-t-1 .  .  64  loop 
af fected_modules (i ) { j ) ; = '  '; 
end  loop; 

TAE_Wpt .Wpt_SetStringConstraints (editstep^info .panel_id 
/ 

"affected",  Taelnt(i),  affected_modules) ; 
end  loop; 
end  i f ; 
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get (data_f ile, counter)  ; 

if  counter  >  0  then  s)cip_line  (data_f  ile)  ; 

get_line (data_f ile, sub_steps, length) ; 

else  s)«ip_line (data_f  ile)  ; 

end  if; 

get (data_f ile, counter ) ; 

if  counter  >  0  then  s)tip_line (data_f ile)  ; 

get_line(data_file. predecessors, length) ; 
end  if; 

text_io.put_line { "done  reading,  writing  to  panel*); 
text_io.put_line( “done  writing  to  panel,  closing  file"); 

text^io. CLOSE (data^f ile) ; 

--  now  write  all  the  step  information  into  the  TAE  window 


Tae_Wpt .Wpt_SetString(editstep_info.panel_id, •base_vers 
ion* , 


base_version) ; 

Tae_Wpt .Wpt^Setlntg (editstep^info.panel^id, “est_duration" , 

Taeint (est_duration) )  ; 

Tae_Wpt .Wpt_SetString{editstep_info.panel_id, *exp_level “ , 

expert ise_ievel ) ; 

Tae_Wpt .Wpt_SetIntg<editstep_info.panel_id, "priority* , 

Taeint (priority) ) ; 

Tae_Wpt .Wpt^SetString (editstep_info .panel_id, "designer" , 

designer) ; 

Tae_Wpt .Wpt_SetString(editstep_info.panel_id, "deadline" , 

deadline) ; 

Tae_Wpt . Wpt_SetString (editstep^inf o . panel_id , *  start_t ime " , 

start_time) ; 

Tae_Wpt . Wpt_SetString { editstep_info .panel_id, " f inish_time" , 

f  inish_tiine)  ; 

Tae_Wpt .Wpt_SetString (editstep_info.panel_id, "pri_input" , 

primary_input) ; 

Tae_Wpt .Wpt_SetIntg {editstep_info .panel_id, *step_number* , 

valued)  )  ; 

Tae_Wpt . Wpt_SetString (editstep_info .panel_id, "sub_steps" , 

sub_steps) ; 
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Tae_Wpt .Wpt_SetString (editstep_info .panel_id, "predecess 
ors", 

predecessors ) ; 


exception 

when  text_io.NAME_ERROR  => 

t;ext_io  .put_line  ( “ERROR:  non-existent  transfer  file 
(probably  ‘ddbdi splay’ ) . “ ) ; 
when  text^io.END_ERROR  => 

text_io.put_line( “ERROR;  corrupt  transfer  file 
(probably  'ddbdisplay * ) . “ ) ; 

if  is_open (data_f ile)  then  close (data_file) ;  end  if; 
when  text_io.STATUS_ERROR  => 

if  is_open (data_f ile)  then  close (data_f ile) ;  end  if; 


end  editnum_s_select_item; 
END  EVENT_HANDLERs 


end  ddb_interface_support ; 

--  ENDFILE:  ddb.interf ace_support_body . a 


--  Main  Program 
begin 

f_force_lower  (FALSE);  --  permit  upper/ lowercase  file  names 
tae_wpt .Wpt_Init  ( “ “ , theDisplay) ; 
tae_wpt . Wpt_NewEvent  (wptEvent ) ; 

initializePanels  ( “ddb_interface.res“ ) ;  --  single  call 

main  event  loop 

EVENT_LOOP : 
loop 

tae_wpt .Wpt_NextEvent  (wptEvent,  etype) ;  --  get  next 

event 
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NOTE:  This  case  statement  includes  STUBS  for  non -WPT_PARM_ EVENT 
events . 

case  etype  is 

when  wpt_eventtype‘ first  ..  -1  =>  null; 

--  iterate  loop  on  Wpt_NextEvent  error 

TYPICAL  CASE:  Panel  Event  ( WPT_PARM_EVENT ) 

when  tae_wpt .WPT_PARM_EVENT  => 

--  You  can  comment  out  the  following  “put"  call. 

--  The  appropriate  EVENT_HANDLER  finishes  the  message. 
text_io.put  (  -Event:  WPT_PARM_EVENT,  -  ); 

Panel  event  has  occurred. 

Get  parm  name  and  then  call  appropriate 
EVENT.HANDLER . 


CAUTION: 

DO  NOT  call  Wpt_Extract_Parm_xEvent  from  any 
other  branch 

of  this  -case-  statement  or  you'll  get 
-storage_error- . 

tae^wpt .Wpt_Extract_Context  (wptEvent,  user_ptr); 
tae_wpt .Wpt_Extract_Parm  (wptEvent, 
user_ptr .parm_name) ; 

tae_wpt .Wpt_Extract^Data  (wptEvent , 
user_ptr.datavm_ptr) ; 

tae_vin.Vin_Pind  {user_ptr .datavm_ptr, 
user_ptr  .pann_name, 

user_ptr .parm_ptr) ; 

--  dummy  if  to  ease  code  generation 
if  (FALSE)  then  null; 

--  WPT_PARM_EVENT,  BEGIN  panel  main 

elsif  tae_wpt.-="  (user_ptr,  main^info)  then 
if  (FALSE)  then  null;  —  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s_equal  ( -selection_l- , 
user_ptr .parm_name)  then 
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end  i f ; 


main_select ion_l  (user_ptr) ; 

--  El^nD  panel  main 

--  WPT_PAPM_EVENT,  BEGIN  panel  editstep 

elsif  tae_wpt.“="  (user_ptr,  editstep_inf o)  then 
if  (FALSE)  then  null;  --  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s_equal  ( "base. version* , 
user^tr  .parm_name)  then 

editstep_base_version  (user_ptr) ; 
elsif  s_equal  ( •pri_input “ ,  user_ptr ,parm_name) 

then 

editstep_pri_input  (user_ptr) ; 
elsif  s_equal  ("predecessors*, 
user_ptr .parm_name)  then 

editstep_predecessors  (user_ptr) ; 
elsif  s_equal  ("priority*,  user_ptr .parm_name) 

then 

editstep_priority  (user_ptr) ; 
elsif  s_equal  ( •exp_level * ,  user_ptr .pann_namej 

then 

editstep_exp_level  (user_ptr) ; 
elsif  s_equal  ("deadline",  user_ptr .pann_name) 

then 

editstep_deadline  (user_ptr) ; 
elsif  s_equal  ( "est_duration* , 
user_ptr .parm_name)  then 

editstep_est_duration  (user_ptr) ; 
elsif  s_equal  ( " sec_input " ,  user_ptr .parm_name) 

then 

editstep_sec_input  (user_ptr) ; 
elsif  s_equal  ("affected",  user_ptr .parm_name) 

then 

editstep_af fected  (user_ptr) ; 
elsif  s_equal  { "return",  user_ptr .parm_name) 

then 

editstep_return  (user_ptr) ; 
elsif  s_equal  ( "apply_step" , 
user_ptr .parm_name)  then 

editstep_apply_step  (user_ptr) ; 
elsif  s_equal  ( "cancel_step" , 
user_ptr .parm_name)  then 

editstep_cancel_step  (user_ptr) ; 
end  if;  --  END  panel  editstep 
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--  WPT_PARM_EVENT,  BEGIN  panel  edit team 


elsif  tae_wpt.*=“  (user_ptr,  editteam_info)  then 
if  (FALSE)  then  null;  --  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s_equal  (“name”,  user_ptr .parm_name)  then 
editteam_name  (user _ptr) ; 
elsif  s_equal  ('•ex_opt",  user_ptr .parm_name) 

then 


then 


then 


editteam_ex_opt  (user_ptr); 
elsif  s_equal  ("d^cancel",  user_ptr .parm_name) 

editteam_d_cancel  (user_ptr) ; 
elsif  s_equal  (“designers",  user_ptr .parm_name) 


editteam_designers  (user_ptr) ; 
elsif  s_equal  ( “select ion_3 " , 
user_pv:r  .parm_name)  then 

editteam_selection_3  (user^ptr) ; 
end  if;  —  END  panel  editteam 


--  WPT_PARM_EVENT,  BEGIN  panel  confirm 

elsif  tae_wpt.“=“  (user_ptr,  conf irm_info)  then 
if  (FALSE)  then  null;  --  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s^equal  (“yes“,  user_ptr .parm_name)  then 
confirmees  (user_ptr)  ; 
elsif  s_e<rial  (“no”,  user_ptr.parm_name)  then 
confinit.no  (user_ptr)  ; 
end  if;  --  END  panel  confirm 

--  WPT_PAPW_BVENT,  BEGIN  panel  s_s elect 

elsif  tae_wpt,“=“  (user_ptr,  s_select_info)  then 
if  (FALSE)  then  null;  --  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s_equal  ( “s_select_item" , 
user_ptr .parm_name)  then 

s_select_s_select_item  (user_ptr) ; 
end  if;  --  END  panel  s_select 
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--  WPT_PARM_EVENT,  BEGIN  panel  showstep 

elsif  tae_wpt.“=‘  (user_ptr,  shows tep_info)  then 
if  (FALSE)  then  null;  --  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s_equal  ( •s_select_item" , 
user_ptr .parm_name)  then 

showstep_s_select_item  (user_ptr) ; 
end  if;  --  END  panel  showstep 

--  WPT_PARM_EVENT,  BEGIN  panel  show 

elsif  tae^wpt."**  (user_ptr,  show_info)  then 
if  (FALSE)  then  null;  --  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s_equal  ( “step_number* , 
user_ptr .patm^name)  then 

show_step_number  (user_ptr) ; 
elsif  s_equal  ( "show_f inish* , 
user_ptr .parm.name)  then 

show_show^f inish  (user_j5tr)  ; 
end  if;  —  END  panel  show 

--  WPT.PARM_EVENT.  BEGIN  panel  textl 

elsif  tae^wpt.“s‘  (user_ptr,  textl_info)  then 
if  (FALSE)  then  null;  —  another  dummy  if 
--  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s_equal  ( "di splay _done* , 
userj>tr .parm^name)  then 

textl_display_done  (user_ptr) ; 
elsif  s^equal  ( ■text_item_l" , 
user_j5tr  .parm^name)  then 

textl^text_item_l  (u3er_ptr) ; 
end  if;  —  END  panel  textl 

--  WPT_PARM_EVENT,  BEGIN  panel  steptype 

elsif  tae_wpt.”  =  '’  (user_ptr,  steptype_info)  then 
if  (FALSE)  then  null;  —  another  dummy  if 
—  determine  appropriate  EVENT_HANDLER  for 

this  item 

elsif  s^equal  ( "type_selection" , 
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user_ptr .parm_name)  then 

steptype_type_selection  (user_ptr) ; 
end  if;  --  END  panel  steptype 

--  WPT_PARM_EVENT,  BEGIN  panel  editnujn 

elsif  tae.wpt.'s*  (user_ptr,  editnuin_info)  then 
if  (FALSE)  then  null;  --  another  dummy  if 
--  determine  appropriate  EV'ENT_HANDLER  for 

this  item 

elsif  s^equal  ( '■s_select_item“ , 
user_ptr .parm_name)  then 

editnum_s_select_item  (user_ptr) ; 
end  if;  --  END  panel  editnum 

else 

text^io  .put_line  { 'unexpected  event  from  wpt ! ' )  ; 
exit;  —  or  raise  an  exception,  but  compiler 
warns  if  no  exit 
end  if; 

when  tae_wpt .WPT^FILE^EVENT  => 

text_io.put_line  ("STUB:  Event 
WPT_FILE_EVENT" ) ; 

--  Use  Wpt_AddEvent  and  Wpt^RemoveEvent  and 
--  Wpt_Extract_Event Source  and 
Wpt_Extract_EventMask 

when  tae_wpt .WPT_TIMEOUT_EVENT  => 

text_io.put_line  ("STUB:  Event 
WPT_TIMEOUT_EVENT" ) ; 

—  Use  Wpt_Set Timeout  for  this 

--  LEAST  LIKELY  cases  follow; 

when  tae_wpt .WPT_WINDOW_EVENT  =>  null  ; 

--  WPT_WINDOW_EVENT  can  be  caused  by  user 
acknowledgement 

--  of  a  Wpt_PanelMessage  or  windows  which  you 
—  directly  create  with  X  (not  TAE  panels) . 
--  You  MIGHT  want  to  use  Wpt_Extract_xEvent_Type 

here . 


‘m. 

•  - 


% 


•f 
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--  EXD  NOT  use  Wpt_Extract_Pann_xEvent  since 

this  is  not 

--  a  WPT_PARM_EVENT;  you'll  get  a  "storage 

error" . 

when  tae_wpt .WPT_HELP_EVENT  =>  --OR  null  ; 

t ext_io . put ( " ERROR :  WPT_HELP_EVENT :  "); 
text_io.put_line( "should  never  see;  reserved 
for  TAE  use"); 

when  t<  ,_wpt.WPT_INTERRUPT_EVENT  =>  --  OR  null  ; 

t ext_io . put ( " ERROR :  WPT_INTERRUPT_EVENT :  "); 
text_io.put_line( "should  never  see;  reserved 
for  TAE  use" ) ; 

when  OTHERS  => 

text_io.put  ("FATAL  ERROR:  Unknown  Wpt.Next Event 
Event  Type :  " )  ; 

text_io.put  ( wpt.event type' image (etype)  )  ; 
text_io.put_line  ( "  ...  Forcing  exit . " ) ; 
exit;  —  or  raise  an  exception 


end  case;  --  NOTE;  Do  not  add  statements  between  here 
and  "end  loop  EVENT_LOOP" 

end  loop  EVENT.LOOP; 

end  ddb_interface; 
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Evolution  Control  System 


Selection 

^  show  protores 
^  shovir  steps 
^  show  step  details 
^  show  schedule 
^  create  prototype 
^  create  stq> 

^  edit  step 
^  edit  team  «> 

^  approve  stiqr 
^  schedule  st^ 

^  commit  step 
O’  suq>end  st^ 

O  abandon  step 

O  cpit 


FIGURE  33.  Screen  image  of  the  ECS  main  menu  (manager) 
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FIGURE  34.  Screen  image  of  the  initial  designer  pool  data 
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FIGURE  36.  Screen  image  of  step  2  details  after  it  has  been  created 
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FIGURE  37.  Screen  image  of  step  3  details  after  it  has  been  created 
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FIGURE  38.  Screen  image  of  step  4  details  after  it  has  been  created 
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FIGURE  39.  Screen  image  of  step  5  details  after  it  has  been  created 
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FIGURE  41.  Screen  image  of  step  6  details  (substep  of  step  1) 
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FIGURE  46.  Image  of  step  10  details  (substep  of  step  2) 
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FIGURE  53.  Screen  image  of  step  7  after  its  completion 
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FIGURE  58.  Screen  image  of  step  3  after  the  completion  of  step  1 
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